<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Daniel et all,
<br>
please find attached a version of the draft RB containing some comments from my side.<br>
<br>
Happy Easter and see you soon in San Antonio, <br>
Dorothea<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF604725" style="direction: ltr;"><font face="Tahoma" size="2" color="#000000"><b>Von:</b> SLS-SEA-DLS [sls-sea-dls-bounces@mailman.ccsds.org]" im Auftrag von "Daniel.Fischer@esa.int [Daniel.Fischer@esa.int]<br>
<b>Gesendet:</b> Mittwoch, 12. April 2017 10:49<br>
<b>An:</b> sls-sea-dls@mailman.ccsds.org<br>
<b>Betreff:</b> [Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3<br>
</font><br>
</div>
<div></div>
<div><font face="sans-serif" size="2">Dear all,</font> <br>
<br>
<font face="sans-serif" size="2">I have finished the update of the SDLS Extended Procedures Draft Red Book. Please find it attached.</font>
<br>
<br>
<br>
<br>
<font face="sans-serif" size="2">Updates included:</font> <br>
<font face="sans-serif" size="2">- Definition of managed parameters for Key Management</font>
<br>
<font face="sans-serif" size="2">- Definition of managed parameters for SU Management and Control</font>
<br>
<font face="sans-serif" size="2">- Inclusion of Key Management and SU Management and Control PDUs in the PICS</font>
<br>
<font face="sans-serif" size="2">- Completed Security Section</font> <br>
<font face="sans-serif" size="2">- Updated Baseline Mode (DK comments, Inclusion of CRC definition provided by Gilles (D 4.3))</font>
<br>
<br>
<font face="sans-serif" size="2">Please note: This is a HUGE document. I am pretty sure there are still a not of small problems in it. If you have some time, could you please check the document for things like this?</font>
<br>
<br>
<font face="sans-serif" size="2"><br>
I am afraid we are not ready for Red Book Status yet. In recent discussions on the mailing list and also with industry a number of questions popped up that need to be clarified first.</font>
<br>
<br>
<font face="sans-serif" size="2">1) SA Management Discussion</font> <br>
<font face="sans-serif" size="2">It was pointed out that the way how keys can be changed on a running SA may not be practicable. At the moment, this requires four SA procedures to be executed. (1) Stoop SA, (2) Expire SA (3) Rekey SA (4) Start SA. However,
it may be preferable to be able to change the keys "on the fly" without having to shut down the SA. This would make key changing much simpler.
</font><br>
<br>
<font face="sans-serif" size="2">2) OTAR/Key Verification Procedures Discussion</font>
<br>
<font face="sans-serif" size="2">The rationale for us to introduce the CRC check was to be able to execute the Key Verification without having to start the lifetime of the key that is being checked. Industry however pointed out that (1) These kind of checks
are usually done by the spacecraft anyway on its memory and (2) That a CRC is not secure and will not guarantee that keys cannot be modified onboard the spacecraft. Instead they suggested to go back to the old Challenge/Response concept but only execute that
prior to activating the session key for operations anyway. In this way, the start of the key lifetime is not a problem.</font>
<br>
<br>
<font face="sans-serif" size="2">3) Use of Master Keys</font> <br>
<font face="sans-serif" size="2">We have specified which procedures are considered sensitive. Industry pointed out that it is still not clear which procedures requires protection under a master key (so far only the OTAR specifies that directly) and in general
what the master keys are being used for. Some of this is in the Symmetric Key Management Book however we should think about if we want to have other procedures especially protected under the use of a master key.</font>
<br>
<br>
<font face="sans-serif" size="2">4) Association of ARC to Key instead of SPI</font>
<br>
<font face="sans-serif" size="2">Industry suggested to associate the ARC to a key rather than an SPI. They argue that is is a more natural connection since a new key would also start a new ARC (TBD). I personally disagree with this but I think its worth discussing
this in the group.</font> <br>
<br>
<font face="sans-serif" size="2">5) Frame Security Report</font> <br>
<font face="sans-serif" size="2">Industry appreciates the concept but has argued that the inclusion of additional error sources (and thus more flags and reduced bits from SN) should be included such as (a) bad MAC, (b) invalid Key/SA state, (c) invalid frame
length. For me this makes sense.</font> <br>
<br>
<font face="sans-serif" size="2">6) Unique Identification of Sender and Receiver VCs.</font>
<br>
<font face="sans-serif" size="2">David has raised the point once more that sender and receiver VCs can currently not be distinguished (since the GVCID is not unique for up and downlinks). A discussion with SLS should take place in the meeting to find a solution
for this since it does not only touch the Extended Procedures. </font><br>
<font face="sans-serif" size="2"><br>
Small things to be approved by the WG:</font> <br>
<font face="sans-serif" size="2">- There seems to be a possible misunderstanding regarding the reserved SPIs. Industry thought that it always has to be exactly the two reserved ones for EP and no more. We may want to add a clarification.</font>
<br>
<font face="sans-serif" size="2">- Discussion on the extend to which the security log is specified in the Extended procedures. Ed suggested the global definition of a GVCIDS and GVCIDR which I personally find a good solution.</font>
<br>
<br>
<br>
<font face="sans-serif" size="2">While this looks like a lot of discussion material, I think we will actually be able to finalise the discussions in the next meeting and then publish the Red Book afterwards.</font>
<br>
<br>
<font face="sans-serif" size="2">Cheers,<br>
Daniel</font> <br>
<font face="sans-serif" size="2"> </font> <br>
<br>
<font face="Verdana" size="1" color="#00a1e0"><b>Dr. Daniel Fischer</b></font><font face="Verdana" size="1" color="#808080"><br>
Head of the Engineering Support Section, OPS-GES<br>
Ground Systems Engineering Department</font> <br>
<font face="Verdana" size="1" color="#808080">Directorate of Operations</font>
<p><font face="Verdana" size="1" color="#808080"><b>ESA - ESOC</b><br>
Robert-Bosch-Str. 5, D-64392 Darmstadt, Germany</font> </p>
<p><font face="Verdana" size="1" color="#808080">Tel. +49 6151 90 2718 | E-mail: Daniel.Fischer@esa.int<br>
</font><br>
<br>
<font face="Arial" size="1" color="#808080"><b><i>Disclaimer</i></b></font> <br>
<font face="Arial" size="1" color="#808080"><i>This message and any attachments are intended for the use of the addressee or addressees only. The unauthorized disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.
If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email.<br>
</i></font><br>
<br>
<font face="Arial" size="1" color="#808080"><b><i>Disclaimer</i></b></font> <br>
<font face="Arial" size="1" color="#808080"><i>This message and any attachments are intended for the use of the addressee or addressees only. The unauthorized disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.
If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email.</i></font></p>
</div>
</div>
</div>
</body>
</html>