Addressing User Credentials and Security in CCSDS Service Interfaces
The discussion revolves around the need to define user credentials within CCSDS service interfaces for enhanced security. Various aspects such as the lack of specific specifications, authentication requirements, and proposed actions for securing service interfaces are highlighted. Suggestions include identifying protected interfaces, assessing existing standards, choosing suitable authentication mechanisms, and producing guidance documents to ensure secure operations without unnecessary complexity.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
CCSDS Security Working Group Credentials (Future) Project 26 June 2015 Howard Weiss NASA/JPL/PARSONS* Identity crisis: Formerly SPARTA Formerly Cobham Formerly SPARTA 1
CCSDS Credentials Background From Peter Shames (SEA Area Director): I do not know if I tossed this one your way, but one of the issues that came up in the SCCS-ARD discussions was that of user credentials. In the SCCS-ARD (final Red-1 draft attached) we pointed out that various service interfaces (SM, SLE, CSTS, future SM&C) have a slot for user credentials, but so far CCSDS is silent on what those might be. Keith pointed this out and insisted, rightly, that we label the use of "CCSDS credentials" a [Future] item because we have no such spec. All of which leaves me wondering if there isn't a nice addition to the Security Algorithms book that would deal with that topic? Or maybe it needs to be addressed as part of the Key Management documents? Somewhere, somehow, I think we need to address this. 3
Additional Background From CSTS framework (CCSDS 921x1): This CSTS Specification Framework defines authentication requirements (see 3.2.4), and defines initiator-identifier, responder-identifier, invoker- credentials, and performer- credentials parameters of the service operation invocations and responses that are used to perform CSTS authentication. 3.2.4.3 Complex Management and Utilization Management shall agree on the algorithm used to generate and check credentials parameters and shall make this algorithm known to the service user and service provider together with associated parameters such as passwords or keys as necessary for the selected algorithm. NOTES a) invocations shall include an invoker-credentials parameter to permit the performer to authenticate the invocation; b) responses shall include a performer-credentials parameter to permit the invoker to authenticate the response. 4
And More Background Additional comments from Peter Shames: The point, I think, is that we should be thinking about ways to make CCSDS service interfaces secure without making the machinery a burden. Right now we just have some empty "slots" in our protocols with no specified way to use them. I think we need to get ahead of this and the Sec WG is the group in the best position to do it. And I do not think we need to invent much ourselves, just to do the following: 1. Identify the service interfaces that need protection (I listed the obvious ones, but there may be others) 2. Survey the CCSDS standards that have these features and make sure you understand their intent and features (ask the WGs for help in this0 3. Evaluate them to see if there is some consistent set of patterns that we need 4. Look at the available, widely used, authentication / credentials mechanisms and pick one (or two) that are suitable for both MMI and HMI 5. Produce a suitably slim document, probably an MB, that says clearly how to do it and points to the best sources for the necessary technology 5
CCSDS Publications Mentioning Credentials CCSDS 910.11-B-1, CCSDS 910.4-B-2, CCSDS 911.1-B- 3, CCSDS 911.2-B-2, CCSDS 911.5-B-2, CCSDS 912.1-B- 3, CCSDS 912.3-B-2, CCSDS 913.1-B-1 CCSDS 520.1-M-1, CCSDS 523.1-M-1, CCSDS 650.0-M- 2, CCSDS 652.1-M-2 , CCSDS 901.1-M-1 , CCSDS 914.0- M-1 , CCSDS 915.1-M-1, CCSDS 915.2-M-1, CCSDS 915.5-M-1, CCSDS 916.1-M-1, CCSDS 916.3-M-1 CCSDS 350.0-G-2, CCSDS 350.6-G-1, CCSDS 901.0-G-1, CCSDS 910.14-G-1, CCSDS 910.3-G-3, CCSDS 914.1-G- 1 CCSDS 912.11-O-1 6
So What Should The SecWG Do? Do we develop a certificate standard a la the IETF RFC 5280 X.509 profile as a blue book? Do we adopt ISO/IEC X.509/9594-8 and call it a day? Do we adopt RFC 5280 and call it a day? Do we do something else? Is a certificate standard all that we need? Do we also need authentication guidance (such as): NIST SP 800-63-2: Electronic Authentication Guideline NIST FIPS 201: Personal Identity Verification OAUTH Reference Architecture (Open AuTHentication) Centers for Medicare & Medicaid Authentication Standards UK Good Practice Guide No. 44: Authentication and Credentials for use with HMG Online Services Is there anything else we should concentrate on? 7
Authentication Credentials What kinds of authentication methodologies should we concern ourselves with? Passwords? One-time passwords? Challenge-response? Transaction signing? User certificates? Biometrics? Device fingerprint (e.g., cookie)? Device certificate? Trusted platform module (TPM)? Smart cards? 8
Comments from Daniel Fischer First, I think that there is a bit of a misunderstanding. When reading Peters input (slide 5), it seems like he is looking for something really simple. Looking in the Internet world, credentials have always been a big issue. The core problem: They are never simple. The other issue is trust, which I think we can ignore for the time being (we can assume that interfacing agencies are able to exchange some kind of root credentials). Regarding Slide 7, I think what Peter is asking for are identity credentials that can be exchanged over a (possibly insecure) channel. For me, this excludes passwords. Since we need to be independent of implementations (at least for the credentials representation itself), I would also not consider biometrics, cookies, TPMs, and smart cards. They are technical solutions to create credentials, but are not describing the credentials themselves. One- time passwords are a possibility and possibly lightweight, however, in this case we have to specify the algorithm, which is quite a restriction. The same comment regarding the algorithm applies to challenge-response. In addition, this requires a two-way interaction, which is not always present in CCSDS standards. I am not an expert in transaction signing, so its a bit hard for me to comment on this one. For me, the best option would be a certificate based solution. A simple number of identity information tags (to be discussed), signed with the private key of the originator. There is also no need to attach the certificate itself all the time I believe. This can be done beforehand. In this case however there is still the question of high-performance solutions..this could be a hybrid solution (public/symmetric system). But for the crypto part of the credential information itself (i.e. the crypto hash) it does not really matter how it is generated (private key or a negotiated symmetric key). 9
Comments Daniel (cont) My suggested approach: We need to define the credentials structure itself ... could be X.509 or a derivate (slim version) and make some assumptions about preconditions We need to check the candidate protocols in CCSDS that should/could adopt it so see whether this is compatible with them We can discuss the algorithms that should be used to sign the credentials...I think we should use the ones we recommend already. The algorithm should however be kept independent from the credentials information itself...like we have done for e.g SLDS or IPsec for Space We need to discuss if we need a green book (I would assume yes...in particular to explain that identify information must be exchanged beforehand somehow i.e. in the form of (root) certificates). 10
Way Forward? What is the way forward? What should we do? Should we tackle just the certificate standard? Should we tackle the guidance? Which piece(s) of the overall puzzle should we tackle first? NOTE: various authentication/credential documents have been uploaded to CWE: SEA-SEC -> Draft Documents -> Credentials 11
