<font size=2 face="sans-serif">Dear all,</font>
<br>
<br><font size=2 face="sans-serif">I have finished the update of the SDLS
Extended Procedures Draft Red Book. Please find it attached.</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Updates included:</font>
<br><font size=2 face="sans-serif">- Definition of managed parameters for
Key Management</font>
<br><font size=2 face="sans-serif">- Definition of managed parameters for
SU Management and Control</font>
<br><font size=2 face="sans-serif">- Inclusion of Key Management and SU
Management and Control PDUs in the PICS</font>
<br><font size=2 face="sans-serif">- Completed Security Section</font>
<br><font size=2 face="sans-serif">- Updated Baseline Mode (DK comments,
Inclusion of CRC definition provided by Gilles (D 4.3))</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif"><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 size=2 face="sans-serif">1) SA Management Discussion</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">2) OTAR/Key Verification Procedures
Discussion</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">3) Use of Master Keys</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">4) Association of ARC to Key instead
of SPI</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">5) Frame Security Report</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">6) Unique Identification of Sender and
Receiver VCs.</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif"><br>
Small things to be approved by the WG:</font>
<br><font size=2 face="sans-serif">- 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 size=2 face="sans-serif">- 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 size=2 face="sans-serif">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 size=2 face="sans-serif">Cheers,<br>
Daniel</font>
<br><font size=2 face="sans-serif"> </font>
<br>
<br><font size=1 color=#00a1e0 face="Verdana"><b>Dr. Daniel Fischer</b></font><font size=1 color=#808080 face="Verdana"><br>
Head of the Engineering Support Section, OPS-GES<br>
Ground Systems Engineering Department</font>
<br><font size=1 color=#808080 face="Verdana">Directorate of Operations</font>
<p><font size=1 color=#808080 face="Verdana"><b>ESA - ESOC</b><br>
Robert-Bosch-Str. 5, D-64392 Darmstadt, Germany</font>
<p><font size=1 color=#808080 face="Verdana">Tel. +49 6151 90 2718 |  E-mail:
Daniel.Fischer@esa.int<br>
</font>
<br>
<br><font size=1 color=#808080 face="Arial"><b><i>Disclaimer</i></b></font>
<br><font size=1 color=#808080 face="Arial"><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 size=1 color=#808080 face="Arial"><b><i>Disclaimer</i></b></font>
<br><font size=1 color=#808080 face="Arial"><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>