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

[Daniel.Fischer at esa.int]

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/20170412/c2d7177e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SDLS Extended Procedures Red 1 v3_no track.docx
Type: application/octet-stream
Size: 1537666 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20170412/c2d7177e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11010 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20170412/c2d7177e/attachment.bin>