SEA Area Report Atlanta, Georgia, USA, 19 September 2005 PS 1
Points to Ponder Things should be as simple as possible, But no simpler. Albert Einstein Internet Robustness Principle Be liberal in what you accept, and conservative in what you send. Jon Postel, RFC 793 & 1122 Though ambition in itself is a vice, Yet it is often a source of virtue. Old Chinese proverb (from Hsu’s Fortune Cookie) Suggested for consideration by all ADs and WG chairs 19 September 2005 PS 2
SEA Meeting Overview • • • 12 Sept, Mon • • AM: CCSDS Plenary, MOIMS coord and other discussions PM: SEA Plenary and Overview 13 Sept, Tues • • AM: SAWG Mtg PM: SAWG Mtg 14 Sept, Wed • • AM: Sec. WG and Info. Arch. WG in parallel PM: Sec. WG and XML Stds SIG in parallel 15 Sept, Thurs • • AM: Sec. WG and SANA Bo. F in parallel PM: Sec. WG and other WG meetings 16 Sept, Fri • • • 19 September 2005 AM: SGIA Bo. F Kickoff PM: SEA summary including WG reports PM (late): CESG tag up PS 3
System Engineering Area Overview • SEA Includes: • • • System Architecture, Information Architecture & Security Working Groups SANA Bo. F (seeking WG status now) SGIA Bo. F (initial meeting) XML Standards and Guidelines SIG (initial meeting) Responsibilities • • 19 September 2005 Overall architecture for space mission communications, operations, and cross-support Coordinate and collaborate with the other areas about architectural choices and options Support the CESG in evaluating consistency of all area programs of work with the defined architecture Create such working groups and Bo. Fs as are required to progress the work of CCSDS PS 4
System Engineering Area Summary: Current WGs and BOFs • • • System Architecture WG - Met this week Develop a high level system architecture reference model and formal methodology and tools. Finalize Reference Architecture for Space Data Systems (RASDS) V 1 Magenta Book Discuss how to progress future work on architectural formalisms Information Architecture WG - Met this week Develop a high level Information Architecture reference model and definitions of active and passive information objects Finalize Reference Architecture for Space Information Management (RASIM) V 1 Green Book Discuss how / where to begin work to define component interfaces and standards Security WG - Met this week Develop security overview & threat assessment, and security architecture, framework and related standards Progress Security Architecture and other specific security elements (Key management, Crypto and Authentication Standards) Discussions with other WGs as needed 19 September 2005 PS 5
System Engineering Area Summary: Current WGs and BOFs • SANA Bo. F - Met this week • Develop detailed requirements for the Space Assigned Numbers Authority (SANA), an implementation approach and a plan for a rapid prototype to demonstrate functionality • Finalize SANA charter • Demo SANA prototype New Bo. F & SIGs • Space Ground Interoperability Architecture (SGIA) Bo. F - Met this • • week Develop an end to end space / ground cross support architecture and services catalog in response to IOAG request • Initiate SGIA charter discussions, create shared vision for task XML Standards & Guidelines (XSG) SIG - Met this week • Develop guidelines and standard approaches for XML schema and namespaces, short fuse due to immediate WG needs • Created agreed task concept, identified chair and members, initiated discussions 19 September 2005 PS 6
System Engineering Area Summary: Current WGs and BOFs New Bo. F & SIGs, contd • Delta-DOR End to End Processing - brief discussion this week • Develop an end to end approach to Delta-DOR processing, including RF signals, data reception, raw data capture & transmission, data processing, delivery of products and ancillary information such as quasar catalogs • Initiate discussions, create shared vision for task and where / how the work should be carried out, co-location problems • Data Management / Data Accountability - brief discussion this week • Develop an end to end data management and data accountability approach • Initiate discussions, create shared vision for task and where / how the work should be carried out 19 September 2005 PS 7
SAWG Executive Summary 1. Review of the RASDS document was done by the SAWG members and an expert on RM-ODP. Some issues were found but the WG agreed to necessary updates to the document. 2. It was agreed to send the updated RASDS document, based on the discussion at this meeting, to CESG and CMC for approval as a Recommended Practice document. 3. It was also agreed that the work on development of a RASDS formal model should be continued in some form (preferably by a CCSDS Bo. F/WG) leveraging the liaison relationship established with the ISO/IEC group developing “UML for ODP. ” 19 September 2005 PS 8
SAWG Summary Technical Status 1. Systems Architecture WG Goal: Develop a reference architecture and a formal representation method Working Group Status: Active ___ Idle ___ Will be terminated _X_ Working Group Summary Situation: Status: Comment: OK CAUTION PROBLEM Must be terminated Working Group Summary progress: • Updated the RASDS document (near BCP), • Started to develop a formal model (before WB) Problems and Issues: • Ordered by CMC to terminate • Development of formal model is deemed essential by SAWG 19 September 2005 PS 9
SAWG Summary of Goals and Deliverables 1. Define a reference architecture that provides a framework for generation of space data systems standards and development of space data systems. 2. Document the reference architecture identifying basic elements. 3. Develop a document that provides to the other Working Groups and Bo. Fs guidelines on how to apply the reference architecture. 4. Develop formal methods for representing space data d ppe sharing of systems architectures that willoenable t k S engineers. architectural informationoamong r 5. Develop tools that. WG W will facilitate design, modeling, and SA simulation of system architectural designs. 19 September 2005 PS 10
SAWG Progress Achieved 1. With regard to items 1 and 2 (see the previous page), a review of the RASDS document was by the SAWG members and an expert on RM-ODP. The WG agreed to necessary updates to the document and the final draft of the document will delivered shortly. 1. Change the”attribute” section to “characteristics” section 2. Define Software & Hardware Engineering Objects 3. Clarify Viewpoint Specifications vs. Views 4. Change order of the sections for better flow 2. With regard to item 4, it was agreed that it should be developed by another Bo. F/WG of CCSDS with a close liaison relationship with the ISO/IEC WG that is developing “UML for ODP. ” 19 September 2005 PS 11
SAWG Near-Term Schedule • The SAWG will be terminated after delivering the final Recommended Practice document to CESG. • Some members of SAWG will participate in the activities of SGIA and there is an intention to use the RASDS to develop SGIA. • A draft charter for a Bo. F that develops a formal model of space data systems will be generated. • In the meantime, some of us (at least NASA, CNES and JAXA), as representatives from the space community, plan to review “UML for ODP” and generate comments. 19 September 2005 PS 12
SAWG Risk Management Update • We believe that one of the reasons why RASDS is not accepted well within CCSDS may be that we haven’t successfully shown how it can be used in space data systems. • SGIA is seen as a means to validate the RASDS concepts by applying them to a real problem that the IOAG and CMC have posed. • JAXA has a plan to use RASDS to develop a database that stores information on spacecraft with a standard format. The concept of the database in the first phase is shown in the next slides. • JPL has a research task that is also extending RASDS to describe space systems. 19 September 2005 PS 13
Sec. WG Executive Summary • Attendees from CNES, BNSC (telecon), NASA/GSFC, NASA/ Langley (telecon), ESA/ESOC (a first!), DLR, NASA/JPL & NASA/GRC (brief) • Discussed and revised the Sec. WG 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 keybased authentication, HMAC-SHA 1 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 (aggregates of public data may be a security risk). 19 September 2005 PS 14
Sec. WG 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. status: OK Working Group Docs OK. New is advancing and work OK. producing good products. CAUTION PROBLEM Resources – always need more Progress since last meeting: Completed Green Book, completed Threat document, completed Encryption and Authentication Trade Studies – agreed on algorithms Problems and Issues: Resources – need to ensure continued participation from all member agencies 19 September 2005 PS 15
Sec. WG 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. 19 September 2005 PS 16
Sec. WG Near-Term Schedule Deliverable Green Book revisions Threat Document CCSDS Security Architecture (5 nd Draft) Encryption Algorithm 19 September 2005 Milestone • Completed – awaiting CESG poll comments • Publish a draft document (White Book) • • Red Book-1 Red Book-2 Blue Book-1 Trade Study completed • Agreement to adopt algorithm • Blue Book planned Date Done 12/05 03/06 07/06 06/05 09/05 PS 17
Sec. WG Near Term Schedule (cont) Authenticati on/Integrity • Trade study completed • Agreement reached on algorithm adoption • Blue Book planned 19 September 2005 08/05 09/05 02/06 PS 18
Sec. WG Near Term 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 19 September 2005 PS 19
IAWG Executive Summary • Six people attended the IA meeting from JPL, GSFC, Marshall and CSA. • The draft Reference Architecture for Space Information Management Green Book was discussed • • Included the updates from the NASA TIM that occurred in August. Established much improved convergence between GSFC and JPL with respect to the relationship between IA and OAIS. Chapter 2, the information model, requires more substantial updates than Chapter 3, the functional information management components. The afternoon IAWG session was canceled in lieu of the meeting on XML best practices (XSG SIG) 19 September 2005 PS 20
IAWG Summary Technical Status 1. Information Architecture WG Goal: Develop a reference architecture for space information management as extension to RASDS Working Group Status: Active _X_ Idle ___ Working Group Summary Situation: Status: Comment: OK CAUTION Transition Unclear PROBLEM Working Group Summary progress: • Updated the RASIM document (nearly complete GB), • Discussed how to transition to development of components & interfaces Problems and Issues: • Agreement on transition is still unclear • Availability of agency participants with right skill set is uncertain 19 September 2005 PS 21
IAWG Progress Achieved • Significant progress has been achieved since July and we have received quite a few positive comments. • Participants seems willing to continue their involvement and to see the Green Book get published. • Some discussion occurred on the need to develop more examples to clarify use of abstract components to build different classes of information systems. • Some discussion occurred on the need for a TIM on registries, at least at the NASA level, but broader participation is welcomed. 19 September 2005 PS 22
IAWG Near Term Schedule 19 September 2005 PS 23
IAWG Open Issues • Similarities exist between “Reference Architecture for Space Information Management” and the OAIS, but differences are: • • OAIS is an archival reference model and process that focuses on preservation and data archives. Data model is specific to archiving. IA focuses on a cross-cutting information management reference architecture applicable across mission lifecycle and components that can be used to build a variety of informtion management systems. • May need to develop a separate process model for the RASIM end to end information infrastructure • Modeling notations and disagreement on how to best render an architecture still continues to be problematic • 19 September 2005 Using UML class diagrams for components, interfaces and data models PS 24
IAWG Resource & Coordination Issues • Participation by individuals with solid experience architecting data-driven systems • IA-related meetings occurring in multiple places (Atlanta and Toulouse) which prevents adequate cross-group interactions. • There may not be commitments from member agencies for enough resource to achieve deliverables. • ESA and CNES considered important stakeholders, but participation has been very limited. • Critical that a combined registries effort be initiated across existing groups. • XSG SIG discussion identified need for schema registry, other have been identified • Once it completes current high priority task XSG SIG may form nucleus for discussion of this topic 19 September 2005 PS 25
SANA BOF Executive Summary • • SANA BOF on 15 September 2005 in Atlanta, GA • Intention • • • 8 representatives included NASA (JPL, GSFC, MSFC), ESA Establish plan, processes and recommended practices for CCSDS Space Assigned Numbers Authority (SANA) Define content, overall approach, and means for updating included information Define how the SANA would work with different CCSDS WGs, registries, and with agency specific elements Establish practice for future maintenance and sustaining of the SANA Motivation: • Primarily provide access to CCSDS global information - Manage central info centrally as authoritative source - Support local management of distributed agency & mission info, provide central pointers to their authoritative sources • Existing SANA is largely conceptual, as defined in CCSDS A 02. 1 -Y-2. Restructured • “SANA” materials are in some existing repositories and also are buried within a number of different CCSDS documents Users have a very difficult time locating these within the CCSDS web site and understanding how they relate one to the other • Organization and Processes for the Consultative Committee for Space Data Systems. Yellow Book. Issue 2. April 2004: 19 September 2005 PS 26
SANA BOF Recommendations • Update the SANA charter to reflect agreements from meeting and submit to the CESG for approval • Ensure that the SANA can deal with the complexity of future spaceflight programs, projects and the technologies involved • • • Help reduce stove piping Setup a mechanism to access and apply specific information technologies through registry processes and artifacts (CCSDS common S/W) Introduce information management commonality across operational domains Enable interoperability & reuse (data dictionaries & glossary, schemas, assigned numbers, common name registry) • Provide commonality at the technical & operational level among disparate projects and development organizations • Single point of (common) access for management, technologists, developers and operators to technically relevant CCSDS related information (SANA=web link management) 19 September 2005 PS 27
SANA Bo. F Recommendations, contd • Primary SANA Contents, in order of priority, are to be: • • CCSDS Registries - Common IDs (ground stations, spacecraft and space objects) - Services discovery (cross support, interoperability) - Common Metadata (Data element, dictionary, glossary, acronyms) - Schema - Pointers to agency registry entrypoints Standard Information Models Standard Namespaces Assigned numbers from standards e. g. CCSDS, IETF…. . SCPS-TP: Keith Scott - Vendor IDs for specific implementations i. e. gateway SCPS-TP White Paper - Assignment of Extended Capability Binding Space Identifiers June 23, 2005 Pointers to standard software objects, XFDU plug-ins, applications services and APIs Pointers to reference implementations (XML, coding, compression, protocols, …) Potential future activities: • • Space name and address domains e. g. operational, network…. Messaging e. g. AMS - Continuums, nodes, zones…. . - Message types 19 September 2005 PS 28
SANA Bo. F Objectives • Objective 1: Establish a CCSDS system of registries for space assigned numbers for current and future international space operations and information management. • Objective 2: Coordinate and integrate current registry processes and other operational information into a single unified standardized frameworking with cooperating organizations. • Objective 3: Provide a focal point from which any authorized organization or individual can acquire technically relevant CCSDS registry and other information. • Objective 4: Setup SANA operations group and develop rules and processes to operate and support the SANA and identify the resources needed for the continuing operation, deployment, outreach, and evolution. • Objective 5: Transition this to a working organization under CESG responsibility. 19 September 2005 PS 29
SANA Bo. F Issues & Risk Management • Technical risks: No significant technical risk is involved. Technical risks are low since this is essentially process based. The prototype activity does not entail any cutting edge technologies. • Management risks: • Some management risk is involved including the usual politics and consensus building necessary for success. • Issues: • • • Issues of privacy, ownership of data Issues of security and access to aggregated information International resources for the WG and operations team 19 September 2005 PS 30
SGIA Bo. F Executive Summary • 11 representatives included NASA (JPL, MSFC), ESA and JAXA participation • • Attendees: Shames, Okino, Crichton, Weiss, Yamada, Kearney, Peccia, Gannet, Hughes, Reich, Hartmann Coordination Identified: - • • JPL and MSFC are actively supporting effort ESA has indicated that they will provide some level of support (telecon, email coordination level) – support from existing SAWG members CNES & JAXA are seeking support General agreement on: Charter of SGIA • Some CHANGE in terms of generalization as to the service provider/user model, specifically do not constrain to SLE General agreement on: 5 step process • • Some CHANGE in terms of language to capture iteration and stakeholder feedback towards - the cross support service catalog cross support service architecture Some CHANGE in terms of refinement of the content, including process as well as the level of detail of the cross support service catalog was identified. 19 September 2005 PS 31
SGIA Bo. F Discussion • There was general concern as to what the SGIA architecture would entail: • A specific suggestion was that it may be sufficient to provide gateway interfaces • Possible options are to present interoperability at the gateway level or end-to-end service along with identified confederated nodes and profiles. • Desire to ensure that existing organizational boundaries and implementation approaches are accommodated • Leverage IOAG DRAFT catalog and architecture • Schedule - general belief we could get an initial WB by June 06 meeting • There was some concern about the scope and meaning of “profiles”. 19 September 2005 PS 32
SGIA Bo. F Action Items • Update Charter and process to represent agreements, submit to CESG • Agencies need to identify suitable Technical Point Of Contact (TPOC) within their operational organizations to be participants in the process - TPOC must be able to provide view of current and future services - TPOC will also act as IOAG “stakeholder” and early reviewer of the - • proposed products of the WG Intent is to pursue from top-down and bottom-up approach Expressed need for contact with JAXA, CNES, and DLR (at a minimum) for participation in WG • No representation at meeting from DLR & CNES 19 September 2005 PS 33
SGIA Risk Summary • Not yet getting essential support - 19 September 2005 CCSDS WG Technical Personnel IOAG TPOCs as Active Stakeholders PS 34
XSG SIG Executive Summary • • XSG SIG on 14 September 2005 in Atlanta, GA • Intention • • • 23 representatives included NASA (JPL, GSFC, MSFC), ESA, CNES, OMG SDTF, and other participation Establish guidelines and recommended practices for CCSDS XML schema, naming, and usage before this first set of schema, from several different working groups, become finalized and externally visible Define common rules, naming and style guides, define URL hierarchy and namespace architecture, define versioning and use schema location as a resolvable URL Motivation: • • Get CCSDS namespace and rules sorted out before current standards are finalized Four separate XML schemas are in development, there is no consistency of naming, usage, namespace, etc across them Enable interoperable implementations of SW and systems Create collaborative solutions and an authoritative source for CCSDS and agency use 19 September 2005 PS 35
XSG SIG Recommendations • • • Create a small working group of current XML schema authors and experts to develop short term approach XML Stds & Guidelines SIG • • • Erik Barkley David Berry Lou Reich (chair) Gerry Simon CNES ? (Lapaian acting) ESA ? (Peccia acting) Define a URL hierarchy and namespace architecture Create a naming and style guide, including guidelines for development of schema and namespace Define versioning approach Create a resolvable URL for schema. Location, ( create a CCSDS server for these, future) Define levels of XML schema reusable components (potentially based on the UBL model) Define approach for consistent use of qualified and unqualified types, elements and attributes Get a CCSDS NID by submitting an RFC to IETF, establish base for URN, list of 23 exist now (RFC 3406, May 2005), see also IANA registry of URI (RFC 3986) 19 September 2005 PS 36
XSG SIG Issues • Issue of impact of this stds effort on immediate WG products and schedules? • Approach for current standards, hold until modified or release as Red-1 now with agreement to change before Red-2 is sent out? • How long will it take to develop these top level standards elements? (by Xmas is target) • How long will it take to modify existing XML schema to be compliant? • How to arrange agreements on common schema between CCSDS & OMG? 19 September 2005 PS 37
XSG SIG Action Items • Create CWE area and mailing list • Have initial XSG SIG discussion, review schemas • Plan for XSG SIG working approach • Initial XSG SIG feedback to CESG • Initial XSG SIG Recommendation to CESG • • • Actionee Due date Actionee Due date 19 September 2005 Shames 1 October 2005 (done 14 Sept 05) Reich 16 Sept 05 Reich 23 Sept 05 Reich 4 Nov 05 XSG SIG, Reich 16 Dec 05 PS 38
SEA Liaisons • Sys. ML Partners have developed a system engineering modeling language based upon UML 2. 0. A liaison has been agreed to, which opens up a communication channel between the SEA and Sys. ML groups. The intent is to provide the Sys. ML solution to CCSDS for their validation for application to Space Systems. • Sys. ML agreed to form a liaison w/ CCSDS. SEA, on behalf of CCSDS, has agreed to that liaison and several joint meetings have been held. • The Sys. ML spec is currently at version 0. 9. Four UML tool vendors have demonstrated Sys. ML 0. 9 compliant versions of their tools. A summary presentation is available from the Sys. ML web site. • An informal liaison has been developed with ISO/IEC JTC 1 / SC 7 which is developing an UML for RM-ODP approach. This opens up a useful communication channel between the two groups. The intent is to validate the RASDS to the RM-ODP and to provide feedback to the SC 7 WG it its applicability to Space Systems. • The JTC 1 / SC 7 chair has agreed to establish an informal liaison w/ CCSDS. SEA, on behalf of CCSDS, has agreed to that liaison and a joint meeting and telecons have been held. 19 September 2005 PS 39
SEA Cross Area Coordination • • • CSS: • SGIA role TBD • Transport security • Use of Sec. WG authentication & access control MOIMS: • Coordination between Information Packaging and Registries & Information Architecture, discussions on-going SGIA role TBD Discussions of development of DM / DA Bo. F effort needed Use of RASDS in SM&C doc Use of Sec. WG authentication and security framework • • SIS: • Relationships among AMS, MTS, and MOIMS S/C Mon & Con protocol (SM&C) • SGIA role TBD • Uplink & downlink network layer security SLS: • SGIA role TBD • Uplink & downlink & physical layer security SOIS: • SGIA role TBD • Uplink, downlink & on-board security 19 September 2005 PS 40
Cross Area WG / BOF Issues • IAWG needs on-going coordination with MOIMS Information Packaging and Registries (IPR). • • • Much more partnering is occurring with a focus on how to define an information infrastructure (interfaces, specifications, architecture, components and best practices) Recommend that Bo. F be created for cross-cutting information infrastructure specification (registries, repositories) that gets participation from agency specialists as well as stakeholders IA becoming more important to other groups • • • 19 September 2005 SLE (data dictionaries, XML schemas, …) XML Standards and Guidelines SANA PS 41
Cross Area WG / BOF Issues • Security is a cross-cutting discipline that needs to be included in many other Areas and WGs. • CESG is alerted that other Areas and WG should request support from the Security WG (in addition to the Sec. WG being proactive). • We believe that the mandatory security section in documents will force the other Areas and WG to seek out help. • Propose a Sec. WG overview briefing at the Spring ‘ 06 meeting opening plenary to cover everyone at one time • Security 101 and Sec. WG initiatives within CCSDS 19 September 2005 PS 42
SEA Resolutions to be Sent to CESG and Then to CMC RESOLUTION 1 : SEA-Sec. WG-R-0509 -001 Considering that: 1. 2. The Sec. WG 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). And recognizing that: 1. CCSDS must ensure that security is adequately addressed in our 2. standards, The current wording in the CMC resolution is too weak, The AREA resolves that: The Standard security section should require that include ALL CCSDS documents, not just Blue Books, include the mandatory security section, and … The security section be mandatory and not waived based on resources. ACTION ITEM 1: SEA-Sec. WG-A-0509 -001 Request that the CMC update policy on security section to make it mandatory on all CCSDS documents and to remove simple “resources waiver”. At minimum this should apply to Blue, Orange, and Magenta Books. 19 September 2005 PS 43
Outcomes of Earlier SEA Resolutions Sent to CESG ACTION ITEM 1: SEA-Sec. WG-A-0504 -001 Request that the CMC review Sec. WG scope and requirements for cross support and interoperability with agency security policy experts. ACTION ITEM 1: SEA-Sec. WG-A-0504 -002 Request that the CMC provide adequate resources to the SEA / Sec. WG to accomplish development of encryption and authentication/integrity standards which are fully adapted to the space community and have been profiled, implemented, and tested before becoming CCSDS recommended standards no later than the end of April 2005. ACTION ITEM 3: SEA-A-0504 -001 Request that the CESG develop a clear and unambiguous process for submitting and resolving RIDs no later than the end of May 2005. ACTION ITEM 1: SEA-A-0504 -002 Request that the areas that have developed or are developing reference architectures or service interfaces to provide them to the SAWG and work with the SAWG to ensure that they and their cross area interactions are correctly understood and properly documented. 19 September 2005 PS 44
SEA Other Issues & Concerns • CESG Agreement on definition of “Recommended Practice” • XML Standards & Guidelines SIG resources • SANA coordination with other WGs & agencies • SGIA participation from WGs & IOAG agency TPOC representatives • Delta-DOR end to end process and flow • DM/DA Bo. F and where to do the work 19 September 2005 PS 45
BACKUP SLIDES 19 September 2005 PS 46
SAWG Open Issues 1. The standard “UML for ODP, ” which is being developed by a ISO/IEC WG, should be used as a basis for developing the formal model of RASDS. However, both RM-ODP and RASDS are instances of domain specific reference models and there should be a mechanism to develop domain specific reference models in a coherent way. 1. There is no standard that defines what Views and Viewpoints are. 2. We should develop comments that reflect our concerns and deliver them to both Sys. ML and the UML for RM-ODP groups. 19 September 2005 PS 47
SAWG Action Items 1. Revise the RASDS document based on the discussion at the meeting • Actionee Shames • Due date 30 October 2005 2. Review the RASDS document distributed by Shames • Actionee All • Due date 15 November 2005 3. Edit a Green Book (informational) that explains the concept of RASDS • Actionee Yamada • Due date 30 November 2005 4. Develop a charter of a Bo. F to develop a formal model of RASDS (or something more generic) • Actionee Yamada • Due date 30 October 2005 19 September 2005 PS 48
SAWG Resource Problems • We don’t need any more resources for this WG because it is going to be terminated. 19 September 2005 PS 49
Sec. WG New Working Items, New BOFs, etc. • There is a plan to create a Bo. F at the CCSDS Spring 2006 meeting that defines the charter of a WG that develops a formal model of space data systems. At least two Agencies (NASA and JAXA) is willing to provide necessary resources to support this Bo. F/WG. 19 September 2005 PS 50
JAXA Example of RASDS Use: General Concept of the Database Subsystem/Instrument Designers SIB Generation Tool Standard Spacecraft Model (Supplied as a UML model library) Operations System SIB Access Tool Spacecraft Information Base (SIB) Virtual Spacecraft Definition of Functional Object A 19 September 2005 Testing System Simulator Definition of Information Object X The future versions of the database will contain Nodes, Enterprise Objects, etc. PS 51
JAXA Example of RASDS Use: How the Database is Used This system can be used for testing at test facilities, flight operations at control centers and autonomous operations onboard spacecraft. Generic Monitor and Control System Testing/ Operations Procedure Generic Controller Application SIB Functional Object Definition Information Object Definition 19 September 2005 Generic Data Conversion Communications Protocols PS 52
JAXA Example of RASDS Use: Example of a Functional Object 19 September 2005 PS 53
Sec. WG Progress Achieved • • • Attended and participated in the High Rate Uplink BOF, Cis. Lunar 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. , MD 5, SHA 256, SHA 384, 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 lifecycle. 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. 19 September 2005 PS 54
Sec. WG Open Issues • Key management white book • Support for proximate and long haul domains • Public vs. symmetric keying • Number of round-trips required for public key • 19 September 2005 negotiations Caching of public keys if not on-line negotiation PS 55
Sec. WG Action Items Item Number Action Item: Sec. WG 0905: 1 Add three types of security (file encryption, TLS, and network layer) to the security architecture document. Gavin Kenny 12/05 Sec. WG 0905: 2 Ensure that integrity-only mechanisms in the security architecture are in concert with the authentication algorithm blue book Gavin Kenny 12/05 Sec. WG 0905: 3 Add examples of how the security architecture can be used. Gavin Kenny 12/05 Sec. WG 0905: 4 Ensure that the latest Security Architecture document has been distributed to the working group and posted to CWE Howie Weiss ASAP 19 September 2005 Assigned to: Date Due: PS 56
Sec. WG Action Items (2) Sec. WG 0905: 5 Investigate “standard” AES modes (e. g. , CBC, ECB) for inclusion in the encryption algorithm blue book. Reconcile AES with the security architecture’s allowance of a NULL encryption algorithm Write a blue book to adopt FIPS 197 as a CCSDS encryption algorithm recommendation. Howie Weiss 11/05 Gavin Kenny 12/05 Howie Weiss 12/05 Sec. WG 0905: 8 Formulate a resolution to have the CMC clarify the mandatory security section wording. Howie Weiss ASAP Sec. WG 0905: 9 Write an authentication algorithm blue book Howie Weiss 02/06 Sec. WG 0905: 6 19 September 2005 PS 57
Sec. WG Action Items (3) Sec. WG 0905: 10 Submit the encryption algorithm and authentication algorithm trade studies as Green Books (accompaniment to the yet to be developed blue books). Howie Weiss 02/06 Sec. WG 0905: 11 Memo to Peter Shames regarding Sec. WG discussions on SANA visible information (e. g. , SCIDs) and identify management. Howie Weiss 09/05 19 September 2005 PS 58
Sec. WG Resource Problems • Resources are adequate to perform the current tasks. • Resources are increasing: • ESA/ESOC has provided a new Sec. WG participant and has promised an additional person by the Spring meeting. 19 September 2005 PS 59
Sec. WG 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 80047. • Mission Planning Guide. 19 September 2005 PS 60
Sec. WG Risk Management Update • Must ensure that the current trend of additional resources remains and that resources don’t shrink. 19 September 2005 PS 61
IAWG Action Items • • Send meeting notes, presentations and comments to IAWG • • To: Info Arch WG Members Due: Due September 30, 2005 Add participants to mailing list and send RASIM document to SEA Exec • • To: SEA Exec Due: Due September 2005 Send an updated version of the RASIM Green Book by Oct 10, 2005 • • To: IAWG Members Due: Due October 2005 Send to the RASIM Green Book to the CESG for approval • • 19 September 2005 To: CESG Due: November 2005 PS 62
Скачать презентацию SEA Area Report Atlanta Georgia USA 19 September
65a673c0fcf9b313b22c728fceed935b.ppt