From David.Koisser at esa.int Wed Mar 1 10:02:48 2017 From: David.Koisser at esa.int (David.Koisser at esa.int) Date: Wed, 1 Mar 2017 11:02:48 +0100 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Message-ID: <14201_1488362572_58B69C4C_14201_127_1_OF573C21AC.E596EF2B-ONC12580D6.0031F940-C12580D6.00373086@esa.int> Dear SDLS WG members, John and I have completed setting up the interoperability testing environment and now we are doing a few finishing touches. Whilst doing this a few questions arose regarding the SDLS EP standard: 1. In Section E4.2.2 (in the baseline mode description of Key Activation) and the following key procedures, it defines the Key ID fields to have a length of 16 bits. And then states: "Values 0-65535 shall not be used to reference session keys." Which would be all possible Key IDs and leave none for any session keys. Can you clarify? 2. While we are fairly sure it is implied: Does the M&C procedure Set ARC set the IV instead of the SN parameter in the regarding cases (e.g. AES-GCM)? 3. The standard is not addressing how to distinguish if a GVCID is regarding the TM or TC channels for the Start SA procedure. An example to clarify: A mission wants a different SA assigned on VC 0 for the uplink (e.g. authentication only) than the VC 0 for the downlink (e.g. authenticated encryption). To be able to set this with the Start SA procedure, it needs a way to distinguish between the TC and TM channel mapping to SPIs. As the GVCID is defined as: GVCID = TFVN + SCID + VCID And the 2 bits long TFVN may have the following values: 01 -> AOS; 10 -> Proximity-1; 00 -> TM- *or* TC-SDLP The GVCID alone is not enough to distinguish between TC and TM and we are currently using a custom data structure for unambiguously identifying the channels in the Start SA procedure. Best Regards, David Koisser This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised 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: From Daniel.Fischer at esa.int Fri Mar 31 06:56:41 2017 From: Daniel.Fischer at esa.int (Daniel.Fischer at esa.int) Date: Fri, 31 Mar 2017 08:56:41 +0200 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard Message-ID: Dear all, Could ask you to take a look at the questions that David sent a while go...some of them need answers before a red book can be produced. My take: Q1 is a typo and will be corrected. --> No further discussion needed Q2: This should be the case. What do the others think? Do we need to be explicit there? Q3: This is a critical one and we don't have an answer at the moment. I remember we discussed this in the WG already but I am not sure we came to a conclusion. This needs to be clarified in the standard. Any opinions? 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 ----- Forwarded by Daniel Fischer/esoc/ESA on 31/03/2017 08:51 ----- From: David.Koisser at esa.int To: sls-sea-dls at mailman.ccsds.org Cc: "John P. Lucas" Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" Dear SDLS WG members, John and I have completed setting up the interoperability testing environment and now we are doing a few finishing touches. Whilst doing this a few questions arose regarding the SDLS EP standard: 1. In Section E4.2.2 (in the baseline mode description of Key Activation) and the following key procedures, it defines the Key ID fields to have a length of 16 bits. And then states: "Values 0-65535 shall not be used to reference session keys." Which would be all possible Key IDs and leave none for any session keys. Can you clarify? 2. While we are fairly sure it is implied: Does the M&C procedure Set ARC set the IV instead of the SN parameter in the regarding cases (e.g. AES-GCM)? 3. The standard is not addressing how to distinguish if a GVCID is regarding the TM or TC channels for the Start SA procedure. An example to clarify: A mission wants a different SA assigned on VC 0 for the uplink (e.g. authentication only) than the VC 0 for the downlink (e.g. authenticated encryption). To be able to set this with the Start SA procedure, it needs a way to distinguish between the TC and TM channel mapping to SPIs. As the GVCID is defined as: GVCID = TFVN + SCID + VCID And the 2 bits long TFVN may have the following values: 01 -> AOS; 10 -> Proximity-1; 00 -> TM- *or* TC-SDLP The GVCID alone is not enough to distinguish between TC and TM and we are currently using a custom data structure for unambiguously identifying the channels in the Start SA procedure. Best Regards, David Koisser This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised 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. _______________________________________________ SLS-SEA-DLS mailing list SLS-SEA-DLS at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls 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: -------------- 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: From Gilles.Moury at cnes.fr Fri Mar 31 09:00:00 2017 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Fri, 31 Mar 2017 09:00:00 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: References: Message-ID: <442F062EBF46F247A96B8A50EF3EB6F42A65DC60@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear all, My response to David's questions would be : Q1 : values 0 and 65535 are reserved (for master keys I understand). Text should be modified. Q2 : EP baseline mode relies on SDLS baseline mode. SDLS baseline mode uses AES-GCM. In that case, the SN is replaced by the IV which is 96 bits. Therefore, the Set ARC procedure of the EP baseline mode is actually setting the IV. I would recommend adding this clarification in the EP baseline mode specification and changing the length of the "New anti-replay counter value" field from 64 to 96 bits for consistency with SDLS baseline mode. Q3 : My proposal would be the following: · For the EP baseline mode, a format is specified for the GVCID/GMAPID field of the Start SA PDU with the following sub-fields: o TFVN (4 bits) o SCID (16 bits) o VCID (6 bits) o MAPID (6bits) · Since we have specified TFVN sub-field length as 4 bits, we have 2 spare bits there. We could use one of them to distinguish TC from TM : '000' would code for TC TFVN and '100' would code for TM TFVN, while '001' would code for AOS and '010' for Prox-1 (which is not covered by SDLS by the way). Best regards, Gilles Gilles MOURY CNES Toulouse De : SLS-SEA-DLS [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Daniel.Fischer at esa.int Envoyé : vendredi 31 mars 2017 08:57 À : sls-sea-dls at mailman.ccsds.org Objet : [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard Dear all, Could ask you to take a look at the questions that David sent a while go...some of them need answers before a red book can be produced. My take: Q1 is a typo and will be corrected. --> No further discussion needed Q2: This should be the case. What do the others think? Do we need to be explicit there? Q3: This is a critical one and we don't have an answer at the moment. I remember we discussed this in the WG already but I am not sure we came to a conclusion. This needs to be clarified in the standard. Any opinions? 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 ----- Forwarded by Daniel Fischer/esoc/ESA on 31/03/2017 08:51 ----- From: David.Koisser at esa.int To: sls-sea-dls at mailman.ccsds.org Cc: "John P. Lucas" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > ________________________________ Dear SDLS WG members, John and I have completed setting up the interoperability testing environment and now we are doing a few finishing touches. Whilst doing this a few questions arose regarding the SDLS EP standard: 1. In Section E4.2.2 (in the baseline mode description of Key Activation) and the following key procedures, it defines the Key ID fields to have a length of 16 bits. And then states: "Values 0-65535 shall not be used to reference session keys." Which would be all possible Key IDs and leave none for any session keys. Can you clarify? 2. While we are fairly sure it is implied: Does the M&C procedure Set ARC set the IV instead of the SN parameter in the regarding cases (e.g. AES-GCM)? 3. The standard is not addressing how to distinguish if a GVCID is regarding the TM or TC channels for the Start SA procedure. An example to clarify: A mission wants a different SA assigned on VC 0 for the uplink (e.g. authentication only) than the VC 0 for the downlink (e.g. authenticated encryption). To be able to set this with the Start SA procedure, it needs a way to distinguish between the TC and TM channel mapping to SPIs. As the GVCID is defined as: GVCID = TFVN + SCID + VCID And the 2 bits long TFVN may have the following values: 01 -> AOS; 10 -> Proximity-1; 00 -> TM- *or* TC-SDLP The GVCID alone is not enough to distinguish between TC and TM and we are currently using a custom data structure for unambiguously identifying the channels in the Start SA procedure. Best Regards, David Koisser This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised 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. _______________________________________________ SLS-SEA-DLS mailing list SLS-SEA-DLS at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls 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: From edward.greenberg at jpl.nasa.gov Fri Mar 31 21:24:10 2017 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B)) Date: Fri, 31 Mar 2017 21:24:10 +0000 Subject: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F42A65DC60@TW-MBX-P04.cnesnet.ad.cnes.fr> References: <442F062EBF46F247A96B8A50EF3EB6F42A65DC60@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: <4EF9F303214ADB458948F9AD7A608EB31D5E3002@ap-embx-sp30.RES.AD.JPL> The SCID identifies the Spacecraft. The SOURCE/DESTINATION FLAG identifies the sending side or the receiving side. Thus by including the SOURCE/DESTINATION FLAG into the GVCID/GMAPID you determine the sending side GVCID verses the receiving side GVCID. By simply modifying the term GVCID to GVCIDS for the sending side and GVCIDR for the receiving side you separate the VCs by directionality which is exactly what you want. From: SLS-SEA-DLS [mailto:sls-sea-dls-bounces at mailman.ccsds.org] On Behalf Of Moury Gilles Sent: Friday, March 31, 2017 2:00 AM To: Daniel.Fischer at esa.int; sls-sea-dls at mailman.ccsds.org Subject: Re: [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard Dear all, My response to David's questions would be : Q1 : values 0 and 65535 are reserved (for master keys I understand). Text should be modified. Q2 : EP baseline mode relies on SDLS baseline mode. SDLS baseline mode uses AES-GCM. In that case, the SN is replaced by the IV which is 96 bits. Therefore, the Set ARC procedure of the EP baseline mode is actually setting the IV. I would recommend adding this clarification in the EP baseline mode specification and changing the length of the "New anti-replay counter value" field from 64 to 96 bits for consistency with SDLS baseline mode. Q3 : My proposal would be the following: · For the EP baseline mode, a format is specified for the GVCID/GMAPID field of the Start SA PDU with the following sub-fields: o TFVN (4 bits) o SCID (16 bits) o VCID (6 bits) o MAPID (6bits) · Since we have specified TFVN sub-field length as 4 bits, we have 2 spare bits there. We could use one of them to distinguish TC from TM : '000' would code for TC TFVN and '100' would code for TM TFVN, while '001' would code for AOS and '010' for Prox-1 (which is not covered by SDLS by the way). Best regards, Gilles Gilles MOURY CNES Toulouse De : SLS-SEA-DLS [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Daniel.Fischer at esa.int Envoyé : vendredi 31 mars 2017 08:57 À : sls-sea-dls at mailman.ccsds.org Objet : [Sls-sea-dls] Fw: Question regarding the SDLS EP Standard Dear all, Could ask you to take a look at the questions that David sent a while go...some of them need answers before a red book can be produced. My take: Q1 is a typo and will be corrected. --> No further discussion needed Q2: This should be the case. What do the others think? Do we need to be explicit there? Q3: This is a critical one and we don't have an answer at the moment. I remember we discussed this in the WG already but I am not sure we came to a conclusion. This needs to be clarified in the standard. Any opinions? 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 ----- Forwarded by Daniel Fischer/esoc/ESA on 31/03/2017 08:51 ----- From: David.Koisser at esa.int To: sls-sea-dls at mailman.ccsds.org Cc: "John P. Lucas" > Date: 01/03/2017 11:04 Subject: [Sls-sea-dls] Question regarding the SDLS EP Standard Sent by: "SLS-SEA-DLS" > ________________________________ Dear SDLS WG members, John and I have completed setting up the interoperability testing environment and now we are doing a few finishing touches. Whilst doing this a few questions arose regarding the SDLS EP standard: 1. In Section E4.2.2 (in the baseline mode description of Key Activation) and the following key procedures, it defines the Key ID fields to have a length of 16 bits. And then states: "Values 0-65535 shall not be used to reference session keys." Which would be all possible Key IDs and leave none for any session keys. Can you clarify? 2. While we are fairly sure it is implied: Does the M&C procedure Set ARC set the IV instead of the SN parameter in the regarding cases (e.g. AES-GCM)? 3. The standard is not addressing how to distinguish if a GVCID is regarding the TM or TC channels for the Start SA procedure. An example to clarify: A mission wants a different SA assigned on VC 0 for the uplink (e.g. authentication only) than the VC 0 for the downlink (e.g. authenticated encryption). To be able to set this with the Start SA procedure, it needs a way to distinguish between the TC and TM channel mapping to SPIs. As the GVCID is defined as: GVCID = TFVN + SCID + VCID And the 2 bits long TFVN may have the following values: 01 -> AOS; 10 -> Proximity-1; 00 -> TM- *or* TC-SDLP The GVCID alone is not enough to distinguish between TC and TM and we are currently using a custom data structure for unambiguously identifying the channels in the Start SA procedure. Best Regards, David Koisser This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised 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. _______________________________________________ SLS-SEA-DLS mailing list SLS-SEA-DLS at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls 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: