[Smwg] TGFT certificats mangement prototype and recommandations

Mon Mar 12 05:49:30 UTC 2018

Hi Erik, 

Thanks, I just realized that somehow I missed your exchanges with Howie. Thanks, I will take a lokk.
Regards.
Claudia

-----Message d'origine-----
De : Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov] 
Envoyé : jeudi 8 mars 2018 18:47
À : Ciocirlan Claudia <Claudia.Ciocirlan at cnes.fr>
Cc : CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Objet : RE: TGFT certificats mangement prototype and recommandations

Hello Claudia,

Yes, we have a bit of an open issue to consider for the TGFT recommendation.  The situation as I understand it is that we do have some guidance from security working group with regard to usage of X.509 certificates. But we do not have any guidance on the management of the keys involved -- it is something that the security working group has yet to address. So I think this is where we will need to suggest something "reasonable".  

By way of something perhaps to research we could take a look at KMIP -- please see https://en.wikipedia.org/wiki/Key_Management_Interoperability_Protocol

I will also query the security group about this.

Best regards,
-Erik

-----Original Message-----
From: Ciocirlan Claudia [mailto:Claudia.Ciocirlan at cnes.fr] 
Sent: Thursday, March 8, 2018 8:30 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: RE: TGFT certificats mangement prototype and recommandations

Hi all,
Sorry for my late response, I had a terrible idea of send you an email and leaving the office just after.
If I have the right interpretation of the different emails we do not have a recommendation for the future of TGFT, at least not yet.

As you recall Erik we can make our own choices for the prototype but it will be event better if we adapt to a recommendation. Although the recommendation is not blocking the prototype.

Our proposal for the tests with CAS would be:
1.	we have created a self signed Certification Authority. We will send the certificate for this CA (.crt file) to CAS/NSSC by mail. It will be used to authenticate our server from their side.
2.	CAS/NSSC will create a private key and an associated sign request for their client certificate (.csr file), and send it by mail to us. The key X509 field of the certificate is the O. We expect it to be something like CAS, or CAS/NSSC, or the name of the actual company subcontractor performing the TGFT prototyping. Access will be granted based on that name.
3.	we will sign this certificate with our CA, and send back the signed certificate (.crt file) to CAS/NSSC by mail. It will be used to authenticate the CAS/NSSC client from the server side.

Regards,
Claudia

-----Message d'origine-----
De : Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Envoyé : vendredi 23 février 2018 17:56
À : Ciocirlan Claudia <Claudia.Ciocirlan at cnes.fr> Cc : CCSDS Service Mgmt WG <smwg at mailman.ccsds.org> Objet : RE: TGFT certificats mangement prototype and recommandations

Claudia et al,

I think we have a couple of considerations here. The first of which is how CNES and CAS need to secure their systems with regard to this prototyping effort. Secondly, as this is a CCSDS recommendation under development, what does CCSDS in general recommend for security?

I think for the first consideration it is pretty much up to the prototyping partners negotiate how this shall work and perhaps information from Wes is of use.

For the second consideration, which may have a bearing on the first consideration,  we probably should consult what CCSDS has already recommended for security practices. I believe there already are a number of books that have been published with regard to securing systems that participate with regard to CCSDS standards. Given that CCSDS already has recommendations on security practices I think for TGFT we simply just need to reference the right bits and pieces in terms of CCSDS security profile to be applied.

I will contact the chair of the CCSDS Security WG  to see what if he can offer some guidance.

Best regards,
-Erik 

-----Original Message-----
From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.]
Sent: Friday, February 23, 2018 6:02 AM
To: Ciocirlan Claudia <Claudia.Ciocirlan at cnes.fr>; Colin Haddow/esoc/ESA <Colin.Haddow at esa.int>; lihu at nssc.ac.cn; liuyurong at nssc.ac.cn; weizhang at nssc.ac.cn; CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Cc: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Subject: Re: [Smwg] TGFT certificats mangement prototype and recommandations

Just my opinion ...

If mutual authentication is used, I think the certificates should probably be managed machine-to-machine (not per user/group/etc).  I'm not sure if people normally do mutual authentication with self-signed certificates; I would expect either the server organization runs a CA to generate the client certs, or otherwise that the CA cert that generates client certs is trusted by the server.  If there are only a very small number of clients it's probably not important, but if there are a lot of clients, self-signed certificates could be a hassle to manage.

-----Original Message-----
From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Ciocirlan Claudia
Sent: Friday, February 23, 2018 8:36 AM
To: Colin Haddow/esoc/ESA <Colin.Haddow at esa.int>; lihu at nssc.ac.cn; liuyurong at nssc.ac.cn; weizhang at nssc.ac.cn; CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Cc: Barkley, Erik J (JPL-3970)[Jet Propulsion Laboratory] <erik.j.barkley at jpl.nasa.gov>
Subject: [Smwg] TGFT certificats mangement prototype and recommandations

Hello all,

We have decided upon a connectivity test for the end of March between the CNES and the CAS. 

In order to prepare the testing we need to agree on the protocol (which will be https) and on the certificates. 
For the end of march we propose that each entity generates auto signed certificates and send them to the other party in order to establish the connection and each entity will then be able to make a "https put" of a file or archive. Is that ok for everyone?

That also raises the question of how the certificates will be managed by TGFT. Do we intend to make recommendations in the TGFT or we leave that an open subject? (how the certificates are going to be managed, generates, by user, by group...).
For the yellow book regarding the test reports we have identified a section where we will mark down all the inputs used beyond the requirements and the recommendations of the TGFT.

I excuse myself if this question was already discussed and I am not aware of.

Regards,
Claudia
_______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg
_______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg