[Smwg] TGFT certificats mangement prototype and recommandations

Fri Mar 9 13:32:55 UTC 2018

Erik,

KMIP is a standard to allow interoperability between key servers.  There is a growing industry for key management appliances (and in fact, my youngest son works for one of those KM appliance vendors - Fornetix).  With so many appliances, there came a need to ensure that an enterprise would not be locked into a single key management vendor and hence KMIP which provides a standard basis for interoperability between clients (e.g., desktops, servers) and KM appliances.

So, if Agency A employed Vendor X's KM server and Agency B employed Vendor Y's KM server, KMIP provides the interoperability to allow both vendor's servers to provide KM services w/o and client modifications or tweaks.

regards

howie

________________________________
Howard Weiss, CISSP

PARSONS, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
443-430-8089 (office)
443-494-9087 (cell)
443-430-8238 (fax)
howard.weiss at parsons.com
www.parsons.com

Please consider the environment before printing this message

________________________________________
From: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Sent: Thursday, March 8, 2018 12:52 PM
To: Weiss, Howard
Cc: CCSDS Service Mgmt WG; Shames, Peter M (312B)
Subject: RE: TGFT certificats mangement prototype and recommandations

Hello Howie,

Following up just a bit more, you did mention that perhaps management of keys could be something taken up in the future by the security working group. I'm curious from your expertise, what you make of KMIP (https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Key-5FManagement-5FInteroperability-5FProtocol&d=DwIFAg&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=dT3K0y3n0RD9-56k-UVMPMP98PIQRd2Kzfa-AwqQOww&m=pgjg2nvuaEalJGHHWVwJsngrfEmEwYcWD_pfUoPo9Ms&s=wcvGtnW6Lo8Jbgio6AexSbiY4WeMMIrd50YT8HvYR80&e=)

Not being a security expert it certainly looks interesting/good but I suspect you have far better insight than I do on this kind of thing. Any inputs you have to offer will be much appreciated.

Best regards,
-Erik

-----Original Message-----
From: Barkley, Erik J (3970)
Sent: Monday, February 26, 2018 12:40 PM
To: 'Weiss, Howard' <Howard.Weiss at parsons.com>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>; Shames, Peter M (312B) <Peter.M.Shames at jpl.nasa.gov>
Subject: RE: TGFT certificats mangement prototype and recommandations

Howie,

Okay.  Thanks.  I think that helps inform us (CSSM WG) what we will have to put in our security section for TGFT.

-Erik

-----Original Message-----
From: Weiss, Howard [mailto:Howard.Weiss at parsons.com]
Sent: Monday, February 26, 2018 12:37 PM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>; Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov>
Subject: Re: TGFT certificats mangement prototype and recommandations

Erik

The standard will only specify the certificate and the simple protected authentication.  Maybe a green book at some point in the future could take on the description for managing certs.

howie

________________________________
Howard Weiss, CISSP

PARSONS, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
443-430-8089 (office)
443-494-9087 (cell)
443-430-8238 (fax)
howard.weiss at parsons.com
www.parsons.com

Please consider the environment before printing this message

________________________________________
From: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Sent: Monday, February 26, 2018 3:26 PM
To: Weiss, Howard
Cc: CCSDS Service Mgmt WG; Shames, Peter M (312B)
Subject: RE: TGFT certificats mangement prototype and recommandations

Howie,

X.509 certificate -- well of course, it all comes back to ASN.1!  Yes, I think this helps -- the question that I have then is will the standard for credentials that you allude to have  recommendations re best practice for managing the certificates, etc.

Thanks and any further info much appreciated, -Erik

-----Original Message-----
From: Weiss, Howard [mailto:Howard.Weiss at parsons.com]
Sent: Monday, February 26, 2018 5:16 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>; Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov>
Subject: Re: TGFT certificats mangement prototype and recommandations

Hello Erik

How is fatherhood treating you?

The Security WG is currently working on a standard for "credentials" which specifies an X.509 certificate for CCSDS and as an alternative, simple protected authentication as is specified in SLE.

However, we are currently not working on anything more detailed such as how the certificates are used (e.g., as is described below for HTTPS).

We do have plans to work on application layer security which would specify the use of TLS (or something like it).  Its on our planning list but its not a project as we don't have the resources to work on it yet.

Does this help?

regards

howie

________________________________
Howard Weiss, CISSP

PARSONS, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
443-430-8089 (office)
443-494-9087 (cell)
443-430-8238 (fax)
howard.weiss at parsons.com
www.parsons.com

Please consider the environment before printing this message

________________________________________
From: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Sent: Friday, February 23, 2018 5:53 PM
To: Weiss, Howard
Cc: CCSDS Service Mgmt WG
Subject: FW: TGFT certificats mangement prototype and recommandations

Hello Howie,

I hope this email finds you doing well.

 You may be aware that one of the projects in the Cross Support Services area is Terrestrial Generic File Transfer (TGFT) which is essentially scoped to utilize the CCSDS XFDU standard for packaging one or more files and then a very simple protocol such as HTTP put to send the file or files from one agency to another. As you can see from the email forwarded below, the question of certificate management has come up. My take is that we really should not deal with this in the TGFT recommendation itself but rather rely on security measures and practices recommended by CCSDS (which in this case would of course be emanating from the security working group).

So along these lines I'm curious if the security working group has addressed this kind of thing already (which books should be look at) or is planning to do so in the foreseeable future. Any other thoughts etc. you have to offer will be much appreciated.

Best regards,
-Erik

-----Original Message-----
From: Ciocirlan Claudia [mailto:Claudia.Ciocirlan at cnes.fr]
Sent: Friday, February 23, 2018 5: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 (3970) <erik.j.barkley at jpl.nasa.gov>; karen.l.tuttle at nasa.gov
Subject: 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

NOTICE: This email message and all attachments transmitted with it may contain privileged and confidential information, and information that is protected by, and proprietary to, Parsons Corporation, and is intended solely for the use of the addressee for the specific purpose set forth in this communication. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited, and you should delete this message and all copies and backups thereof. The recipient may not further distribute or use any of the information contained herein without the express written authorization of the sender. If you have received this message in error, or if you have any questions regarding the use of the proprietary information contained therein, please contact the sender of this message immediately, and the sender will provide you with further instructions.