1. Security WG: Report of the Fall 2005 Meeting Atlanta GA September 16, 2004 Howard Weiss NASA/JPL/SPARTA

2. Planned Meeting Agenda  14 September 2005  0900-0915: Welcome, opening remarks, logistics, agenda bashing, 0915-0930: Review results of Spring 2005 SecWG meeting in Athens Mtg Notes Mtg Notes  0930-1000: RASDS Review wrt Security Architecture (Kenny telecon)  1000-1030: coffee break  1030-1200: Security Architecture Document Discussions (Kenny telecon)  1200-1330: Lunch  1330-1400:Review CNES Mission Security Req Development using EBIOS (Pechmalbec/Belbis)  1400-1500: Encryption Algorithm Trade Study (Weiss)  1500-1530: coffee break  1530-1700: Authentication/Integrity Algorithm Trade Study (Weiss)  15 September 2005  0900-1000: Key management discussion (Kenny)  1000-1030: Coffee break  1030-1100: Identity Management, Spacecraft IDs (Weiss)  1100-1130: CNES Interconnection Rules (Pechmalbec/Belbis)  1130-1300: Lunch  1300-1400: CNES Security Development Process (Pechmalbec/Belbis)  1400-1500: Security Policy Document/Common Criteria (Weiss)

3. Attendance NameCompanyEmail Address Howie WeissNASA/JPL/SPARTAhsw@sparta.com Martin PilgramDLRmartin.pilgram@dlr.de Stephane PechmalbecCNESstephane.pechmalbec@cnes.fr Ed CriscuoloNASA/GSFC/CSCed.criscuolo@gsfc.nasa.gov Clayton SigmanNASA/GSFCclayton.sigman@gsfc.nasa.gov Daniel FischerESA/ESOCdaniel.fischer@esa.int Peter ShamesNASA/JPLpeter.shames@jpl.nasa.gov Gavin Kenny (telecon)BNSC/LogicaCMGGavin.ia.kenny@logicacmg.com Fred Stillwagen (telecon) NASA/Langley (SCAWG/SAST) Frederic.h.stillwagen@nasa.gov

4. Executive Summary  Attendees from CNES, BNSC (telecon), NASA/GSFC, NASA/ Langley (telecon), NASA/GRC, ESA/ESOC, DLR, and NASA/JPL.  First participation of an ESA/ESOC representative!  Mario Merri mentioned that ESA/ESOC would also provide another representative in time for the next meeting!  Discussed and revised the SecWG Security Architecture documents  Discussed and accepted proposals for CCSDS standards for:  Encryption (AES w/min 128-bit key, additional algorithms allowed)  Authentication/integrity (Digital Signature Standard for public key- based authentication, HMAC-SHA1 for MAC-based authentication)  Discussed CNES approach to developing security requirements and their use of the EBIOS tool  Discussed the development of:  Security Policy Framework  Information Security Planning Guide Potential usage of Common Criteria to develop mission Protection Profiles  Discussed issues from NASA DSWG – identity management, SCID “exposure” on SANA.

5. Summary of Goals and Deliverables 1. Security Green Book revision is complete and has been submitted to the CESG – poll has just closed – awaiting review comments 2. Threat Document is completed and has been submitted to the CESG – poll has just closed – awaiting review comments. 3. Security Architecture document has undergone another revision taking into account the previous comments – to be sent out for WG review/comments. 4. Trade-off analysis of potential CCSDS encryption standards as a means of deciding on a recommendation was completed and WG recommends distributing as a Green Book for the Encryption Algorithm Blue Book. 5. Trade-off analysis of potential CCSDS authentication standards as a means of deciding on a recommendation was completed and WG recommends distributing as a Green Book for the Authentication Algorithm Blue Book. 6. CCSDS key management standard still in process – controversy regarding public key exchanges vs. shared, symmetric keys. 7. Policy Framework and Mission Planners Guides still in process. 8. Continue to work with other Areas and their WGs with respect to security.

6. Progress Achieved  Attended and participated in the High Rate Uplink BOF, CisLunar WG, and a splinter group of the SLS participants concerning how the Internet protocols work and can be used.  Reviewed the latest incarnation of the Security Architecture document and its relationship with the final version of the RASDS. Area of contention within the Security Architecture revolves around key management issues: architecture is heavily slanted towards public key technologies that may not be universally applicable. Also issues revolving around how to do emergency commanding. More review to occur.  Reviewed the security algorithm trade studies  Encryption: must use AES-128 w/128-bit key at min; additional algorithms may be used at mission/agency/govt discretion.  Authentication/Integrity: dual standards that must be used Digital Signature Algorithm (DSA) for public key-based authentication Hash-based Message Authentication Code (HMAC) using SHA-1 for shared secret- based authentication Other hashing algorithms (e.g., MD5, SHA256, SHA384, UMAC) may be used  Discussed the beginning of the Security Policy Framework Guide – attempt a CCSDS re-write of the NIST Guide (800-47) and a starting point and re-affirmed the adaptation of the NIST document for CCSDS use.  Again discussed the potential use of the Common Criteria for development of mission Protection Profiles. CNES makes heavy use of the CC but does not produce full-blown PPs. The WG did not want to develop PPs (too much boilerplate, too large, too hard to read, etc) but did agree it makes sense to use the CC as a basis for developing mission security requirements and this will be introduced in the mission planners guide that remains to be written.  CNES described their level of security involvement in mission development. CNES has an independent security organization that works hand-in-hand with mission planners to develop the mission security requirements, the threat study, the trade studies, and the security life-cycle. They also discussed the risk analysis tool (available as open source), EBIOS, that they use to develop the mission security requirements. This needs to be examined for potential use by others and maybe to be introduced as a CCSDS recommended practice.

7. SEA Area MID-TERM REPORT SUMMARY TECHNICAL STATUS 1.Security WG Goal: Working Status: Active __X_ Idle ____ Summary progress: Three documents actively being produced (Security Green Book, Security Architecture, Threat). All docs green. Green Book to CESG. Progress since last meeting: Completed Green Book, completed Threat, completed Encryption and Authentication Trade Studies – agreed on algorithms Problems and Issues: Resources – need to ensure continued participation from all member agencies status:OKCAUTIONPROBLEM comment: Working Group is advancing and producing good products. Docs OK. New work OK. Resources – but things are looking much better. ESA/ESOC has now provided someone and promises 1 more.

8. Near-Term Schedule DeliverableMilestoneDate Green Book revisions Completed – awaiting CESG poll comments Threat Document Completed – awaiting CESG poll comments CCSDS Security Architecture (5nd Draft) Publish a draft document (White Book) Red Book-1 Red Book-2 Blue Book-1 Done 12/05 03/06 07/06 Encryption Algorithm Trade Study completed Agreement to adopt algorithm Blue Book to be written 06/05 09/05 12/05

9. Schedule (cont) Authentication /Integrity Trade study completed Agreement reached on algorithm adoption Blue Book to be written 08/05 09/05 02/06

10. Schedule (cont) Key Management document Revise trade analysis for conclusions and recommendations 12/05 First draft Security Policy Guide Develop a rough draft Security Policy Guide based on NIST 800-47 01/06 Mission Planners Security Guide Look at the tailoring of the CCToolbox to develop mission protection profiles 06/06

11. Open Issues  Key management white book  Public vs. symmetric keying  Number of round-trips required for public key negotiations  Caching of public keys if not on-line negotiation

12. Action Items Item NumberAction Item:Assigned to:Date Due: SecWG0905:1Add three types of security (file encryption, TLS, and network layer) to the security architecture document. Gavin Kenny12/05 SecWG0905:2Ensure that integrity-only mechanisms in the security architecture are in concert with the authentication algorithm blue book Gavin Kenny12/05 SecWG0905:3Add examples of how the security architecture can be used. Gavin Kenny12/05 SecWG0905:4Ensure that the latest Security Architecture document has been distributed to the working group and posted to CWE Howie WeissASAP

13. Action Items (2) SecWG0905:5Investigate “standard” AES modes (e.g., CBC, ECB) for inclusion in the encryption algorithm blue book. Howie Weiss11/05 SecWG0905:6Reconcile AES with the security architecture’s allowance of a NULL encryption algorithm Gavin Kenny12/05 SecWG0905:6Write a blue book to adopt FIPS 197 as a CCSDS encryption algorithm recommendation. Howie Weiss12/05 SecWG0905:8Formulate a resolution to have the CMC clarify the mandatory security section wording. Howie WeissASAP SecWG0905:9Write an authentication algorithm blue book Howie Weiss02/06

14. Action Items (3) SecWG0905:10Submit the encryption algorithm and authentication algorithm trade studies as Green Books (accompaniment to the yet to be developed blue books). Howie Weiss02/06 SecWG0905:11Memo to Peter Shames regarding SecWG discussions on SANA visible information (e.g., SCIDs) and identify management. Howie Weiss09/05

15. Resource Problems  Resources are adequate to perform the current tasks.  Resources are increasing:  ESA/ESOC has provided a new SecWG participant and has promised an additional person by the Spring meeting.

16. Risk Management Update  Must ensure that the current trend of additional resources remains and that resources don’t shrink.

17. Cross Area WG / BOF Issues  Security is a cross-cutting discipline that needs to be included in many other Areas and WGs. In the plenary, we asked that the CESG be alerted that other Areas and WG should request support from the Security WG (in addition to the SecWG being proactive). We believe that the mandatory security section in documents will force the other Areas and WG to seek out help!  Met with high rate uplink BOF regarding security concerns.  Met with CisLunar  Maybe provide a SecWG overview briefing at the Spring meeting opening plenary to cover everyone at one time?  Security 101 and SecWG initiatives within CCSDS?

18. Resolutions to be Sent to CESG and Then to CMC  Several concerns:  SecWG is concerned with the lack of feedback from the CESG and CMC. For example, the SecWG sent a resolution up requesting that every CCSDS document contain a standard security section. The return flow indicated this was passed. More than a year later we learn that the language was changed (only blue books, resource problems allow provide a waiver, etc). We believe that the WG need a view into the outcome of the CESG and CMC meetings that does not appear to currently exist.  Clarify what the current security section resolution means, what is required, in what books, what waivers are allowed?  Standard security section resolution should be modified to include ALL CCSDS documents – not just Blue Books. Or at least Orange and Magenta books should be included and maybe also Green books.

19. New Working Items, New BOFs, etc.  Encryption algorithm blue book.  Authentication algorithm blue book.  Security Architecture red book.  Key Management red book.  Security Policy Framework based on NIST 800-47.  Mission Planning Guide.