[Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3

Thu Apr 13 13:31:16 UTC 2017

Daniel et all,
please find attached a version of the draft RB containing some comments from my side.

Happy Easter and see you soon in San Antonio,
Dorothea
________________________________
Von: SLS-SEA-DLS [sls-sea-dls-bounces at mailman.ccsds.org]" im Auftrag von "Daniel.Fischer at esa.int [Daniel.Fischer at esa.int]
Gesendet: Mittwoch, 12. April 2017 10:49
An: sls-sea-dls at mailman.ccsds.org
Betreff: [Sls-sea-dls] SDLS Extended Prcocedures Red Book Draft 1.3

Dear all,

I have finished the update of the SDLS Extended Procedures Draft Red Book. Please find it attached.

Updates included:
- Definition of managed parameters for Key Management
- Definition of managed parameters for SU Management and Control
- Inclusion of Key Management and SU Management and Control PDUs in the PICS
- Completed Security Section
- Updated Baseline Mode (DK comments, Inclusion of CRC definition provided by Gilles (D 4.3))

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?

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.

1) SA Management Discussion
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.

2) OTAR/Key Verification Procedures Discussion
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.

3) Use of Master Keys
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.

4) Association of ARC to Key instead of SPI
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.

5) Frame Security Report
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.

6) Unique Identification of Sender and Receiver VCs.
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.

Small things to be approved by the WG:
- 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.
- 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.

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.

Cheers,
Daniel

Dr. Daniel Fischer
Head of the Engineering Support Section, OPS-GES
Ground Systems Engineering Department
Directorate of Operations

ESA - ESOC
Robert-Bosch-Str. 5, D-64392 Darmstadt, Germany

Tel. +49 6151 90 2718 |  E-mail: Daniel.Fischer at esa.int

Disclaimer
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.

Disclaimer
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20170413/4f551a9a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SDLS Extended Procedures Red 1 v3_no track_DR.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 1543541 bytes
Desc: SDLS Extended Procedures Red 1 v3_no track_DR.docx
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20170413/4f551a9a/attachment.docx>