Security WG: Report of the Spring 2004 Meeting May 13, 2004 Howard Weiss, NASA/JPL/SPARTA

Meeting Agenda  Wed, 12 May 2004  : Welcome, opening remarks, logistics, agenda bashing  0915:0930: Review results of Fall 2003 SecWG meeting (SEA- SEC_Report)SEA- SEC_Report  : Security Architecture Document Discussions  : lunch break  : Threat Document Discussions  Thurs, 13 May 2004  : Revised Green Book discussions  : New business Mandatory security section in CCSDS documents Crypto standard Integrity Standard Authentication Standard Key Management Future Documents

Executive Summary  Attendees from ASI (2), CNES, BNSC, NASA/GSFC (via telecon), DLR, NASA/JPL  Discussed the SecWG documents in process:  Security Architecture  Threat  Revised Green Book  Discussed and re-wrote the “mandatory security section” for CCSDS documents  Discussed and have proposals for CCSDS standards for:  Encryption  Authentication/integrity  Have agreed to think more about key management alternatives

Summary of Goals and Deliverables 1. Complete update/revision of the Security Green Book. 2. Complete update/revision of Security Architecture. 3. Complete update/revision of Threat Document. 4. Propose a CCSDS encryption standard. 5. Propose a CCSDS authentication standard. 6. Think about proposals for a CCSDS key management standard. 7. Work with other WGs with respect to security.

Progress Achieved  Agreed that we did not need a common set of “mission classes” for all SecWG documents:  High level set of mission classes for architecture  More detailed (lower level) set of mission classes for threat  Re-wrote the “mandatory security” statement.  Agree to propose low level security standards:  Encryption AES-128  Authentication/Integrity Digital Signature Standard  Agreed to further study key management  Key updating  Identity-based encryption (IBE)

Re-worded Mandatory Security Statement  Propose to include a security section template for all CCSDS documents with headings and explanatory text to help authors fill in the blanks.  Outline of security section:  Provide rationale and explanation as to why or why not security plays a role in this CCSDS document.  Template headings: 1.0 Security Background/Introduction 2.0 Statements of security concerns with respect to the CCSDS document:  data privacy  data integrity  authentication of communicating entities  control of access to resources  availability of resources  auditing of resource usage 3.0 Potential threats and attack scenarios (how could someone break the technology and why) 4.0 Consequences of not applying security to the technology (e.g., loss of life, loss of mission).

Near-Term Schedule DeliverableMilestoneDate Green Book revisions Comments received from WG Publish a revised book for CCSDS approval 06/04 CCSDS Security Architecture (2nd Draft) Publish a draft document (White Book) Red Book-1 Red Book-2 Blue Book-1 06/04 10/04 04/05 10/05 Revise Security Threat Statement with revised “mission classes” Revise with new mission classes 06/04

Schedule (cont) Encryption ProposalWrite up proposal for CCSDS encryption standard based on AES /04 Authentication/Integrity Proposal Write up proposal for CCSDS authentication/inte grity standard based on the Digital Signature Standard 08/04

Open Issues  Key management proposal  Policy framework  E.g., NIST document could be leveraged but will take resources to adapt for CCSDS. Resources not available at present.  Ground systems  Security for the ground system  Interconnection/policy for cross support across ground systems  Future documents – resources to tackle them  Common Criteria Protection Profiles  Security Handbook for Mission Planners

Action Items  Update Security Architecture based on WG comments (Kenny)  Update mission classes  “Ratify” Security Architecture via vetting by other working groups (e.g., SOIS, CSS, SLS) (Weiss/Kenny)  Investigate national encryption export/import rules and regulations (Pechmalbec, all)  Prepare key management alternatives proposal paper (Kenny)  Public key techniques  Identity-based techniques  Key update techniques  Ensure continued interaction with DTN program (Weiss)  Update Threat Document with revised mission classes (Weiss)  Update Green Book based on ASI comments (to be supplied) (Weiss)  Post Identity-based encryption papers on DocuShare (Weiss)  Post WG slides on DocuShare (Weiss)  Post/ AIST key management report (after obtaining NASA release authorization) (Weiss)

Resource Problems  Resources are adequate to perform the initial tasks.  It has not yet been determined if resources are adequate to accomplish all the work currently on the schedule.  There was no ESA representation at this meeting which means that a large portion of CCSDS membership was not represented. This should must be fixed.

Risk Management Update  It is still unclear if enough resources are available from the Agencies to perform the necessary jobs.

Cross Area WG / BOF Issues  Security is a cross-cutting discipline that needs to be included in many other Areas and WGs. We discussed how this would be best performed – by having other WGs come to the Security WG for help or by having the Security WG go to the other groups to provide support.  It was felt that the proactive approach would work best but resource constraints will be an issue.  “Ratify” security architecture via vetting by other working groups  SOIS  SLS  CSS

Resolutions to be Sent to CESG and Then to CMC  Propose to include a security section template for all CCSDS documents with headings and explanatory text to help authors fill in the blanks.  Outline of security section:  Provide rationale and explanation as to why or why not security plays a role in this CCSDS document.  Template headings: 1.0 Security Background/Introduction 2.0 Statements of security concerns with respect to the CCSDS document:  data privacy  data integrity  authentication of communicating entities  control of access to resources  availability of resources  auditing of resource usage 3.0 Potential threats and attack scenarios (how could someone break the technology and why) 4.0 Consequences of not applying security to the technology (e.g., loss of life, loss of mission).

Resolutions to be Sent to CESG and Then to CMC  Resolution to the CESG to have the SecWG create a CCSDS security recommendations blue book, with the first standards being:  Proposal for a profile for an encryption standard based on FIPS 197 specification of AES-128  Proposal for a profile for an authentication/integrity standard based on FIPS specification of the Digital Signature Standard.

New Working Items, New BOFs, etc.  Encryption recommendation.  Authentication recommendation.  Key Management recommendation.