OMG DDS Security Specification - 4th revised submission document

2,067 views
1,973 views

Published on

NOTE: This document has been obsoleted by the Adopted DDS Specification

OMG DDS Security Draft Specification. This is the 4th Revised Submission to the DDS Security Specification.
Also accessible from the OMG at:
http://www.omg.org/members/cgi-bin/doc?mars/13-02-15.pdf

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,067
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OMG DDS Security Specification - 4th revised submission document

  1. 1. Date: March 2013 revised submissionDDS SecurityJoint Revised Submission____________________________________________________OMG Document: dds/2013-02-15(March 2013 revised submission)________________________________________________Submission Contacts:Gerardo Pardo-Castellote, Ph.D. (lead)CTO, Real-Time Innovations, Inc.gerardo@rti.comJaime Martin-LosaCTO, eProsima.jaime.martin@eprosima.comAngelo Corsaro, Ph.D.CTO, PrimsTech.angelo.corsaro@prismtech.com
  2. 2. Copyright © 2011, Object Management Group, Inc. (OMG)Copyright © 2010, Real-Time Innovations, Inc. (RTI) USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICESThe material in this document details an Object Management Group specification in accordancewith the terms, conditions and notices set forth below. This document does not represent acommitment to implement any portion of this specification in any companys products. Theinformation contained in this document is subject to change without notice. LICENSESThe company listed above have granted to the Object Management Group, Inc. (OMG) anonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document andto modify this document and distribute copies of the modified version. Each of the copyrightholders listed above has agreed that no person shall be deemed to have infringed the copyright inthe included material of any such copyright holder by reason of having used the specification setforth herein or having conformed any computer software to the specification.Subject to all of the terms and conditions below, the owners of the copyright in this specificationhereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license(without the right to sublicense), to use this specification to create and distribute software andspecial purpose specifications that are based upon this specification, and to use, copy, anddistribute this specification as provided under the Copyright Act; provided that: (1) both thecopyright notice identified above and this permission notice appear on any copies of thisspecification; (2) the use of the specifications is for informational purposes and will not becopied or posted on any network computer or broadcast in any media and will not be otherwiseresold or transferred for commercial purposes; and (3) no modifications are made to thisspecification. This limited permission automatically terminates without notice if you breach anyof these terms or conditions. Upon termination, you will destroy immediately any copies of thespecifications in your possession or control. PATENTSThe attention of adopters is directed to the possibility that compliance with or adoption of OMGspecifications may require use of an invention covered by patent rights. OMG shall not beresponsible for identifying patents for which a license may be required by any OMGspecification, or for conducting legal inquiries into the legal validity or scope of those patentsthat are brought to its attention. OMG specifications are prospective and advisory only.Prospective users are responsible for protecting themselves against liability for infringement ofpatents.
  3. 3. GENERAL USE RESTRICTIONSAny unauthorized use of this specification may violate copyright laws, trademark laws, andcommunications regulations and statutes. This document contains information, which isprotected by copyright. All Rights Reserved. No part of this work covered by copyright hereinmay be reproduced or used in any form or by any means--graphic, electronic, or mechanical,including photocopying, recording, taping, or information storage and retrieval systems--withoutpermission of the copyright owner. DISCLAIMER OF WARRANTYWHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "ASIS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENTGROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANYKIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIEDWARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR APARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENTGROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORSCONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL,CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OFPROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRDPARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THISMATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.The entire risk as to the quality and performance of software developed using this specification isborne by you. This disclaimer of warranty constitutes an essential part of the license granted toyou to use this specification. RESTRICTED RIGHTS LEGENDUse, duplication or disclosure by the U.S. Government is subject to the restrictions set forth insubparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause atDFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software -Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of theDoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the FederalAcquisition Regulations and its successors, as applicable. The specification copyright owners areas indicated above and may be contacted through the Object Management Group, 140 KendrickStreet, Needham, MA 02494, U.S.A. TRADEMARKSMDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® andXMI® are registered trademarks of the Object Management Group, Inc., and Object
  4. 4. Management Group™, OMG™ , Unified Modeling Language™, Model Driven ArchitectureLogo™, Model Driven Architecture Diagram™, CORBA logos™, XMI Logo™, CWM™,CWM Logo™, IIOP™ , MOF™ , OMG Interface Definition Language (IDL)™ , and OMGSysML™ are trademarks of the Object Management Group. All other products or companynames mentioned are used for identification purposes only, and may be trademarks of theirrespective owners. COMPLIANCEThe copyright holders listed above acknowledge that the Object Management Group (actingitself or through its designees) is and shall at all times be the sole entity that may authorizedevelopers, suppliers and sellers of computer software to use certification marks, trademarks orother special designations to indicate compliance with these materials.Software developed under the terms of this license may claim compliance or conformance withthis specification if and only if the software compliance is of a nature fully matching theapplicable compliance points as stated in the specification. Software developed only partiallymatching the applicable compliance points may claim only that the software was based on thisspecification, but may not claim compliance or conformance with this specification. In the eventthat testing suites are implemented or approved by Object Management Group, Inc., softwaredeveloped using this specification may claim compliance or conformance with the specificationonly if the software satisfactorily completes the testing suites.
  5. 5. OMG’s Issue Reporting ProcedureAll OMG specifications are subject to continuous review and improvement. As part of this proc-ess we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they mayfind by completing the Issue Reporting Form listed on the main web page http://www.omg.org,under Documents, Report a Bug/Issue (http://www.omg.org/technology/agreement.)
  6. 6. Table of Contents1   Response  Details .....................................................................................................................1   1.1   OMG  RFP  Response ....................................................................................................................... 1   1.2   Copyright  Waiver........................................................................................................................... 1   1.3   Contacts ........................................................................................................................................ 1   1.4   Problem  Statement ....................................................................................................................... 1   1.5   Overview  of  this  Specification ....................................................................................................... 2   1.6   Design  Rationale............................................................................................................................ 4   1.7   Statement  of  Proof  of  Concept ...................................................................................................... 4   1.8   Resolution  of  RFP  Requirements  and  Requests.............................................................................. 4   1.9   Responses  to  RFP  Issues  to  be  discussed........................................................................................ 4  2   Scope ......................................................................................................................................6  3   Conformance...........................................................................................................................6   3.1   Changes  to  Adopted  OMG  Specifications ....................................................................................... 6   3.2   Compliance  Levels ......................................................................................................................... 6  4   Normative  References .............................................................................................................7  5   Terms  and  Definitions .............................................................................................................7  6   Symbols...................................................................................................................................7  7   DDS  Security............................................................................................................................8   7.1   Security  Model .............................................................................................................................. 8   7.1.1   Threats ...........................................................................................................................................9   7.2   Securing  DDS  Messages ............................................................................................................... 12   7.2.1   RTPS  Background  (Non-­‐Normative) .............................................................................................12   7.2.2   Secure  RTPS  Messages .................................................................................................................14   7.2.3   Platform  Independent  Description...............................................................................................15   7.2.4   Mapping  to  UDP/IP  PSM ..............................................................................................................17  8   Plug-­‐in  Architecture............................................................................................................... 18   8.1   Security  Exception ....................................................................................................................... 20  DDS Security, Revised Submission i
  7. 7. 8.1.1   Operation:  init..........................................................................................................................21   8.1.2   Operation:  get_message .........................................................................................................21   8.1.3   Operation:  get_code ................................................................................................................21   8.1.4   Operation:  get_minor_code ..................................................................................................21   8.2   Property ...................................................................................................................................... 21   8.3   Credential.................................................................................................................................... 22   8.3.1   Attribute:  credential_classid ..........................................................................................23   8.3.2   Attribute:  properties .............................................................................................................23   8.3.3   Attribute:  value .........................................................................................................................23   8.4   Token .......................................................................................................................................... 23   8.4.1   Attribute:  token_classid ......................................................................................................24   8.4.2   Attribute:  wrapper_classid .................................................................................................24   8.4.3   Attribute:  properties .............................................................................................................24   8.4.4   Attribute:  value .........................................................................................................................25   8.4.5   Attribute:  wrapped_value ......................................................................................................25   8.5   DDS  support  for  plugin  message  exchange .................................................................................. 25   8.5.1   ParticipantMessageData  kinds  reserved  by  this  specification .....................................................26   8.5.2   Format  of  data  within  ParticipantMessageData ..........................................................................26   8.6   Authentication  Plug-­‐in................................................................................................................. 27   8.6.1   Background  (Non-­‐Normative) ......................................................................................................27   8.6.2   Authentication  Plug-­‐in  Model ......................................................................................................28   8.7   Access  Control  Plug-­‐In ................................................................................................................. 40   8.7.1   Background  (Non-­‐Normative) ......................................................................................................40   8.7.2   Access  Control  Plug-­‐in  Model.......................................................................................................41   8.8   Cryptographic  Plug-­‐in .................................................................................................................. 56   8.8.1   Cryptographic  Plug-­‐in  Model........................................................................................................56   8.8.2   Attribute:  transformation_kind_id.................................................................................58   8.8.3   Attribute:  transformation_key_id ...................................................................................58   8.9   The  Logging  Plugin....................................................................................................................... 86   8.9.1   Background  (Non-­‐Normative) ......................................................................................................86  ii DDS Security, Revised Submission
  8. 8. 8.9.2   Logging  Plug-­‐in  Model ..................................................................................................................86   8.10   Data  Tagging.............................................................................................................................. 89   8.10.1   Background  (Non-­‐Normative) ....................................................................................................89   8.10.2   Approach ....................................................................................................................................89   8.10.3   DataTagging  Model ....................................................................................................................89   8.11   Security  Plug-­‐ins’  Behavior ........................................................................................................ 91   8.11.1   Authentication  and  AccessControl  behavior  with  local  DomainParticipant ..............................91   8.11.2   Authentication  behavior  with  remote  DomainParticipant.........................................................92   8.11.3   AccessControl  behavior  with  local  domain  entity  creation........................................................95   8.11.4   AccessControl  behavior  with  remote  entity  discovery ..............................................................96   8.11.5   Security  Plugins  behavior  for  key  propagation...........................................................................98   8.11.6   Security  Plugins  behavior  for  encoding/decoding....................................................................102  9   Builtin  Plugins ..................................................................................................................... 111   9.1   Requirements  and  priorities ...................................................................................................... 111   9.1.1   Performance  and  Scalability.......................................................................................................112   9.1.2   Robustness  and  Availability........................................................................................................113   9.1.3   Fitness  to  the  DDS  Data-­‐Centric  Model......................................................................................113   9.1.4   Leverage  and  reuse  of  existing  security  infrastructure  and  technologies..................................114   9.1.5   Ease  of  use  while  supporting  common  application  requirements .............................................114   9.2   Builtin  Authentication:  DDS:Auth:PKI-­‐RSA/DSA-­‐DH ................................................................... 114   9.2.1   Configuration..............................................................................................................................115   9.2.2   DDS:Auth:PKI-­‐RSA/DSA-­‐DH  Types ..............................................................................................115   9.2.3   Behavior  of  the  DDS:Auth:PKI-­‐RSA/DSA-­‐DH  plugin....................................................................118   9.2.4   Wire  protocol  implemented  by  the  DDS:Auth:PKI-­‐RSA/DSA-­‐DH  plugin.....................................125   9.3   Builtin  Access  Control  Plugin:  DDS:Access:PKI-­‐Signed-­‐XML-­‐Permissions .................................... 127   9.3.1   Configuration..............................................................................................................................127   9.3.2   DDS:Access:PKI-­‐Signed-­‐XML-­‐Permissions  Types ........................................................................131   9.3.3   Behavior  of  the  builtin  Access  Control  Plugin ............................................................................132   9.4   Builtin  Cryptographic  Plugin ...................................................................................................... 135   9.4.1   Configuration..............................................................................................................................136  DDS Security, Revised Submission iii
  9. 9. 9.4.2   DDS:Crypto:AES-­‐CTR-­‐HMAC-­‐RSA/DSA-­‐DH  Types .......................................................................136   9.4.3   Behavior  of  the  DDS:Crypto:AES-­‐CTR-­‐HMAC-­‐RSA/DSA-­‐DH  Plugin .............................................140   9.5   Builtin  Logging  Plugin ................................................................................................................ 151  References ................................................................................................................................ 151  iv DDS Security, Revised Submission
  10. 10. PrefaceOMGFounded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profitcomputer industry standards consortium that produces and maintains computer industry specifica-tions for interoperable, portable, and reusable enterprise applications in distributed, heterogeneousenvironments. Membership includes Information Technology vendors, end users, government agen-cies, and academia.OMG member companies write, adopt, and maintain its specifications following a mature, openprocess. OMG’s specifications implement the Model Driven Architecture® (MDA®), maximizingROI through a full-lifecycle approach to enterprise integration that covers multiple operating sys-tems, programming languages, middleware and networking infrastructures, and software develop-ment environments. OMG’s specifications include: UML® (Unified Modeling Language™);CORBA® (Common Object Request Broker Architecture); CWM™ (Common Warehouse Meta-model); and industry-specific standards for dozens of vertical markets.More information on the OMG is available at http://www.omg.org/.OMG SpecificationsAs noted, OMG specifications address middleware, modeling and vertical domain frameworks. ASpecifications Catalog is available from the OMG website at:http://www.omg.org/technology/documents/spec_catalog.htmSpecifications within the Catalog are organized by the following categories:OMG Modeling Specifications• UML• MOF• XMI• CWM• Profile specificationsOMG Middleware Specifications• CORBA/IIOP• Data-Distribution Service (DDS) Specifications• IDL/Language MappingsDDS Security, Revised Submission v
  11. 11. • Specialized CORBA specifications• CORBA Component Model (CCM)Platform Specific Model and Interface Specifications• CORBAservices• CORBAfacilities• OMG Domain specifications• OMG Embedded Intelligence specifications• OMG Security specificationsAll of OMG’s formal specifications may be downloaded without charge from our website. (Productsimplementing OMG specifications are available from individual suppliers.) Copies of specifications,available in PostScript and PDF format, may be obtained from the Specifications Catalog cited aboveor by contacting the Object Management Group, Inc. at:OMG Headquarters140 Kendrick StreetBuilding A, Suite 300Needham, MA 02494USATel: +1-781-444-0404Fax: +1-781-444-0320Email: pubs@omg.orgCertain OMG specifications are also available as ISO standards. Please consult http://www.iso.org.Typographical ConventionsThe type styles shown below are used in this document to distinguish programming statements fromordinary English. However, these conventions are not used in tables or section headings where nodistinction is necessary.Times/Times New Roman - 10 pt.: Standard body textHelvetica/Arial - 10 pt. Bold: OMG Interface Definition Language (OMG IDL) and syntaxelements.Courier - 10 pt. Bold: Programming language elements.Helvetica/Arial - 10 pt: ExceptionsNOTE: Terms that appear in italics are defined in the glossary. Italic text also represents the nameof a document, specification, or other publication.vi DDS Security, Revised Submission
  12. 12. PART I - Introduction 1 Response Details 1.1 OMG RFP Response This specification is submitted in response to the DDS Security RFP issued in December 2010 with OMG document number mars/ /2010-12-37. 1.2 Copyright Waiver “Each of the entities listed above: (i) grants to the Object Management Group, Inc. (OMG) a nonex- clusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version, and (ii) grants to each member of the OMG a nonexclusive, royalty-free, paid up, worldwide license to make up to fifty (50) copies of this document for internal review purposes only and not for distribution, and (iii) has agreed that no per- son shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used any OMG specification that may be based hereon or having con- formed any computer software to such specification.” 1.3 Contacts • Real-Time Innovations – Gerardo Pardo-Castellote, Ph.D. gerardo.pardo@rti.com • eProsima – Jaime Martin-Losa Jaime.martin@eprosima.com • PrimsTech – Angelo Corsaro, Ph.D. Angelo.Corsaro@prismtech.com 1.4 Problem Statement Current DDS Systems meet Information Assurance requirements by isolating DDS applications into a security enclave running at "system high". Inside the "protected domain" applications are author- ized to publish and subscribe to any data in the DDS Global Data Space. Once inside the protected domain applications are not authenticated; unless done at the application layer data and meta-data is sent unencrypted and it is not protected against tampering, data is often sent using multicast. Stated differently, the standard OMG DDS infrastructure provides no guarantees (other than those provided by the physical protection of the system) on confidentiality, pedigree, or integrity of the information. What is needed is a set of Information Assurance extensions to the DDS standard that provide the necessary support for Authentication, Authorization and Access Control, Confidentiality, Integrity, and Non-repudiation for all the data sent over DDS. Moreover, a Security Auditing capability is also necessary to evaluate the state of the global data space. One possible approach would be to enforce Mandatory Access Control (MAC) on all applications that join a DDS Global Data-Space, requiring them to be authenticated and have the necessary cre- DDS Security, Revised Submission 1
  13. 13. dentials. Beyond access to the DDS Global Data Space, the approach should provide finer-grain (e.g.role-based or more generally, policy-based) access control to specific DDS Topics and perhaps evento specific fields within DDS Topics. It should ensure confidentiality of the information, integrity,pedigree, and non-repudiation. Finally, it should be able to handle the scalable publish-subscribe de-ployment scenarios, specifically the one-to-many (multicast) distribution of encrypted informationand maintain the DDS real-time QoS in the distribution of information to multiple subscribers.The required Security Architecture needs to be configurable (e.g. via newly added QoS polices) toprovide simple access to standard, interoperable, pre-defined security policies out-of-the box. At thesame time, the architecture should remain open and extensible (e.g. via “plug-in” SPIs) so that appli-cation developers can integrate with pre-existing Identity Management Mechanisms, AuthorizationPolicy repositories, or cryptographic libraries, which might be program or project specific.1.5 Overview of this SpecificationThis specification defines the Security Model and Service Plugin Interface (SPI) architecture forcompliant DDS implementations. The DDS Security Model is enforced by the invocation of theseSPIs by the DDS implementation. This specification also defines a set of built-in implementations ofthese SPIs. • The specified built-in SPI implementations enable both out-of-the box security and interoper- ability between compliant DDS applications. • The use of SPIs allows DDS users to customize the behavior and technologies that the DDS implementations use for Information Assurance, specifically allowing customization of Authentication, Access Control, Encryption, Message Authentication, Digital Signing, Log- ging and Data Tagging.2 DDS Security, Revised Submission
  14. 14. This specification defines five SPIs; combined they provide Information Assurance to DDS systems: • Authentication Service Plug-in. Provides the means to verify the identity of the application and/or user that invokes operations on DDS. Includes facilities to perform mutual authentica- tion between participants and establish a shared secret. • AccessControl Service Plug-in. Provides the means to enforce policy decisions on what DDS related operations an authenticated user can perform. For example which domains it can join, which Topics it can publish or subscribe, etc. • Cryptographic Service Plug-in. Implements (or interfaces with libraries that implement) all cryptographic operations, including encryption, decryption, hashing, digital signatures, etc. Includes the means for key derivation from a shared secret. • Logging Service Plug-in. Supports auditing of all DDS security-relevant events • Data Tagging Service Plug-in. Provides a way to add tags to data samples.DDS Security, Revised Submission 3
  15. 15. 1.6 Design Rationale1.7 Statement of Proof of Concept1.8 Resolution of RFP Requirements and RequestsThe specification resolves the following mandatory requirements:Table 1. Mandatory RFP RequirementsRequirement Description Reference Remarks6.5.16.5.16.5.36.5.46.5.5The proposed specification addresses the following optional requirements:Table 2. Optional RFP RequirementsRequirement Description Reference Remarks6.6.16.6.26.6.36.6.46.6.56.6.66.6.76.6.81.9 Responses to RFP Issues to be discussedThe specification discusses the following issues:4 DDS Security, Revised Submission
  16. 16. Table 3. RFP Issues to be DiscussedIssue Description Reference Remarks6.7.16.7.26.7.36.7.46.7.5DDS Security, Revised Submission 5
  17. 17. PART II – PIM and Language PSMsfor DDS Security 2 Scope This submission adds an additional “DDS Security Support” compliance point (“profile”) to the DDS Specification with the following scope: • Authentication Plug-in • Access Control Plug-in • Data Tagging API • Cryptography Plug-in • Key Management Plug-in • Logging Plug-in 3 Conformance 3.1 Changes to Adopted OMG Specifications This specification does not modify any existing adopted OMG specifications. It adds functionality on top of the current OMG specifications. • DDS: This specification does not modify or invalidate any existing DDS profiles or compli- ance levels. • RTPS: This specification depends on the definitions of CDR “parameter list” data structures specified by RTPS. It does not require any modifications to RTPS, however it impacts interoperability with existing DDS/RTPS implementations. In particular, DDS/RTPS imple- mentations that do not implement this specification will not interoperate with implementa- tions that do implement the mechanisms introduced by this proposal. The interoperability is still achieved if the security mechanisms are disabled. • IDL: This specification does not modify any existing IDL-related compliance levels. 3.2 Compliance Levels There is a single compliance level to this specification. This compliance level shall be considered a “DDS Security” Profile of the DDS Specification. 6 DDS Security, Revised Submission
  18. 18. 4 Normative ReferencesRFC 20145 Terms and DefinitionsFor the purposes of this specification, the following terms and definitions apply.Data-Centric Publish-Subscribe (DCPS)The mandatory portion of the DDS specification used to provide the functionality required for an ap-plication to publish and subscribe to the values of data objects.Data Distribution Service (DDS)An OMG distributed data communications specification that allows Quality of Service policies to bespecified for data timeliness and reliability. It is independent of implementation languages.Information AssuranceThe practice of managing risks related to the use, processing, storage, and transmission of informa-tion or data and the systems and processes used for those purposes.AuthenticationSecurity measure designed to establish the identity of a transmission, message, or originator.Access ControlMechanism that enables an authority to control access to areas and resources in a given physical fa-cility or computer-based information system.ConfidentialityAssurance that information is not disclosed to unauthorized individuals, processes, or devices.IntegrityProtection against unauthorized modification or destruction of information.Non-RepudiationAssurance the sender of data is provided with proof of delivery and the recipient is provided withproof of the senders identity, so neither can later deny having processed the data.6 SymbolsPKIHMACDDS Security, Revised Submission 7
  19. 19. This specification does not define any symbols or abbreviations.7 DDS Security7.1 Security ModelThe Security Model for DDS must define the security principals (users of the system), the objectsthat are being secured, and the operations on the objects that are to be restricted. DDS applicationsshare information on DDS Global Data Spaces (called DDS Domains) where the information is or-ganized into Topics and accessed by means of read and write operations on data-instances of thoseTopics.Ultimately what is being secured is a specific DDS Global Data Space (domain) and within the do-main the ability to access (read or write) information (specific Topic or even Topic-Instances) in theDDS Global Data Space.Securing DDS means providing • Confidentiality of the data samples • Integrity of data samples and the messages that contain them • Authentication of DDS writers and readers • Authorization of DDS writers and readers • Non-repudiation of dataTo provide secure access to the DDS Global Data Space applications that use DDS must first beauthenticated, such that the identity of the application (and potentially the user that interacts with it)can be established. Once authentication has been obtained, the next step is to enforce access controldecisions that determine whether the application is allowed to perform specific actions. Examples ofactions are: joining a DDS Domain, defining a new Topic, reading, or writing a specific DDS Topic,and even reading or writing specific Topic instances (as identified by the value of the key fields inthe data). Enforcement of the access control shall be supported by cryptographic techniques such thatinformation confidentiality and integrity can be maintained, which in turn requires an infrastructureto manage and distribute the necessary cryptographic keys.8 DDS Security, Revised Submission
  20. 20. 7.1.1 ThreatsIn order to understand the decisions made in the design of the plugins it is important to understandsome of the specific threats impacting applications that use DDS and DDS Interoperability Protocol(RTPS).Most relevant are four categories of threats: 1. Unauthorized subscription 2. Unauthorized publication 3. Tampering and replay 4. Unauthorized access to dataThese threats are described in the context of a hypothetical communication scenario with 6 actors allattached to the same network: • Alice. A DDS DomainParticipant that is authorized to publish data on a Topic T. • Bob. A DDS DomainParticipant that is authorized to subscribe to data on a Topic T. • Eve. An eavesdropper. Someone that is not authorized to subscribe to data on Topic T. However Eve uses the fact that it is connected to the same network to try to see the data. • Trudy. An intruder. A DomainParticipant that is not authorized to publish on Topic T. However Trudy uses the fact that it is connected to the same network to try to send data. • Mallory. A Malicious DDS DomainParticipant. Mallory is authorized to subscribe to data on topic T but it is not authorized to publish on Topic T. However Mallory will try to use in- formation gained by subscribing to the data to publish in the network and try to convince Bob that she is a legitimate publisher. • Trent. A Trusted service that needs to receive information on Topic T and also send it. For example, Trent can be a persistence service or a relay service. It is trusted to relay informa- tion without having malicious intent. However it is not trusted to see the content of the in- formation.DDS Security, Revised Submission 9
  21. 21. 7.1.1.1 Unauthorized SubscriptionThe DomainParticipant Eve is connected to the same network infrastructure and is able to observethe network packets despite the fact that the messages are not intended to be sent to Eve. Many sce-narios can lead to this situation. Eve could tap into a network switch or observe the communicationchannels. Or in situations where Alice and Bob are communicating over multicast Eve could simplysubscribe to the same multicast address.Protecting against Eve is reasonably simple. All that is required is for Alice to encrypt the data itwrites using a secret key that is only shared with authorized receivers such as Bob, Trent, and Mal-lory.7.1.1.2 Unauthorized PublicationThe DomainParticipant Trudy is connected to the same network infrastructure and is able to injectnetwork packets with any data contents, headers and destination it wishes (e.g Alice). The networkinfrastructure will route those packets to the indicated destination.In order to protect against Trudy, Bob, Trent and Mallory need to realize that the data is not originat-ing with Alice. They need to realize that the data is coming from someone not authorized to senddata on topic T and therefore reject (i.e. not process) the packet.Protecting against Trudy is also reasonably simple. All that is required is for the protocol to requirethat the messages include either a hash-based message authentication code (HMAC) or digital signa-ture. • An HMAC creates a message authentication code using a secret key that is shared with the intended recipients. Alice would only share the secret key with Bob, Mallory and Trent so that they recognize messages that originate in Alice. Since Trudy is not authorized to publish Topic T, Bob and the others will not recognize any HMACs that Trudy produces (i.e. they will not recognize Trudy’s key).10 DDS Security, Revised Submission
  22. 22. • A Digital Signature is based on public key cryptography. To create a Digital Signature Alice encrypts a digest of the message using Alice’s private key. Everybody (including Bob, Mal- lory and Trent) have access to Alice’s public key. Similar to the HMAC above, the recipients can identify the messages from Alice, as they are the only ones whose digital signature can be interpreted with Alice’s public key. Any digital signatures that Trudy may use will be re- jected by the recipients as Trudy was not authorized to write topic T.The use of HMAC versus Digital Signatures represents tradeoffs that will be discussed further insubsequent sections. Suffice it to say that in many situations the use of HMAC is preferred as theperformance to compute and verify them is about 1000 faster than the performance of comput-ing/verifying digital signatures.7.1.1.3 Tampering and ReplayMallory is authorized to subscribe to Topic T, Therefore Alice has shared with Mallory the secretkey to encrypt the topic and also, in the case HMAC is used, the secret key used for HMAC.Assume Alice used HMAC instead of digital signatures. Then Mallory can use the knowledge it hasof the secret keys used for data-encryption and HMAC to create a message on the network and pre-tend it came from Alice. Mallory can fake all the TCP/UDP/IP headers and also place any necessaryRTPS identifiers (e.g. Alice’s RTPS DomainParticipant and DataWriter GUIDs). Mallory has thesecret key that was used to encrypt the data so it can create encrypted data payloads with any con-tents it wants. It has the secret key used to compute HMAC so it can also create a valid HMAC forthe new message. Bob and the others will have no way to see that message came from Mallory andwill accept it thinking it came from Alice.So if Alice used HMAC the only solution to the problem is that the secret key used for HMAC whensending the message to Mallory cannot be the same it uses when sending messages to Bob. In otherwords Alice must share a different secret key for HMAC with each recipient. That way Mallory willnot have the HMAC key that Bob expects from Alice and the messages from Mallory to Bob will notbe misinterpreted as coming from Alice.Recall that Alice needs to be able to use multicast to communicate efficiently with multiple receiv-ers, Therefore if Alice wants to send an HMAC with a different key for every receiver, the only solu-tion is to append multiple HMACs to the multicast message with some key-id that allows the recipi-ent to select the correct HMAC to verify.If Alice used digital signatures to protect the integrity of the message, then this ‘masquerading’ prob-lem does not arise and Alice is able to send the same digital signature to all recipients. This makesthe use of multicast simpler. However the performance penalty of using digital signatures is so highthat in many situations it will be better to compute and send multiple HMACs as described earlier.7.1.1.4 Unauthorized access to data by infrastructure servicesInfrastructure services, such as the DDS Persistence Service or relay services need to be able to re-ceive messages, verify their integrity, store them, and send them to other participants on behalf of theoriginal application.DDS Security, Revised Submission 11
  23. 23. These services can be trusted to not be malicious, however often it is not desirable to grant them theprivileges they would need to understand the contents of the data. They are allowed to store and for-ward the data, but not to see inside the data.Trent is an example of such service. To support deployment of these types of services it is necessarythat the security model supports the concept of having a participant, such as Trent, that is allowed toreceive, process, and relay RTPS messages, but is not allowed to see the contents of the data withinthe message. In other words it can see the headers and sample information (writer GUID, sequencenumbers, keyhash and such) but not the message contents.In order to support services like Trent, Alice needs to accept Trent as a valid destination to its mes-sages on topic T and share with Trent only the secret key used to compute the HMAC for Trent, butnot the secret key used to encrypt the data itself. In addition Bob, Mallory and others need to acceptTrent as someone that is able to write on topic T, and moreover relay messages from Alice. Thismeans two things, (1) accept and interpret messages encrypted with Alice’s secret key and (2) allowTrent to include in its sample information the information it got from Alice (writer GUID, sequencenumber and anything else needed to properly process the relayed message).Assume Alice used HMAC in the message sent to Trent. Trent will have received from Alice the se-cret key needed to properly verify the HMAC. Trent will be able to store the messages, but lackingthe secret key used for encryption it will be unable to see the data. When it relays the message toBob, it will include the information that indicates the message originated in Alice and produce anHMAC with its own secret HMAC key that it shared with Bob. Bob will receive the message, verifythe HMAC and then see it is a relayed message from Alice. Bob recognizes Trent is authorized torelay messages so it will accept the sample information that relates to Alice and process the messageas if it had originated with Alice. In particular it will use Alice’s secret key to decrypt the data.If Alice had used digital signatures then Trent has two choices. If the digital signature covers onlythe data and the sample information it needs to relay from Alice it could then just relay the digitalsignature as well. Otherwise it can strip that and put its own HMAC. Similar to before, Bob recog-nizes that Trent is allowed to relay messages from Alice and will be able to properly verify and proc-ess the message.7.2 Securing DDS MessagesOMG DDS uses the Real-Time Publish-Subscribe (RTPS) on-the-wire protocol (also an OMG stan-dard) for communicating data. The RTPS protocol includes specifications of how discovery is per-formed, the meta-data sent during discovery, and all the protocol messages and handshakes requiredensuring reliability. RTPS also specifies how messages are put together.7.2.1 RTPS Background (Non-Normative)In a secure system where efficiency and message latency is also a consideration, it is necessary todefine exactly what needs to be secured. Some applications may require only the data payload to beconfidential and it is acceptable for the discovery information as well as the reliability meta-traffic(HEARTBEATs, ACKs, NACKs, etc.) to be visible as long as it is protected from modification.Other applications may want to keep the meta-data (sequence numbers, in-line QoS) and/or the reli-ability traffic (ACKs, NACKs, HEARTBEATs) also confidential. In some cases the discovery in-formation (who is publishing what and the QoS) may need to be kept confidential as well.12 DDS Security, Revised Submission
  24. 24. To help clarify these requirements, this section explains the structure of the RTPS Message and thedifferent Submessages it may contain.An RTPS Message is composed of a leading RTPS Header followed by a variable number of RTPSSubmessages. Each RTPS Submessage itself composed of a Sub-message Header fol-lowed by a variable number of SubmessagElements. There are various kinds ofSubmessageElements to communicate thngs like sequence numbers, unique identifiers forDataReaders and DataWriters, SerializedKeys or KeyHash of the application data, source time-stamps, QoS, etc. There is one kind of SubmessageElement called SerializedData that isused to carry the data sent by DDS Applications.For the purpses of securing comminications we may distinguish three types of RTPSSubmessages: 1. DataWriter Submesages. These are the RTPS submessages sent by a DataWriter to one or more DataReaders. These include the Data, DataFrag, Gap, Heartbeat, and HeartbeatFrag submessages. 2. DataReader Submesages. These are the RTPS submessages sent by a DataReader to one or more DataWriters. These include the AckNack and the NackFrag submessages 3. Interpreter Submesages. These are the RTPS submessages that are destined to the Message Interpereter and affect the interpretation of subsequents submessages. These include all the “Info” messages.DDS Security, Revised Submission 13
  25. 25. The only RTPS Submessages that contain application data are the Data and DataFrag. The appli-cation data is contained within the SerializedData submessage element. In addition to theSerializedData these submessages contain sequence numbers, inline QoS, the Key Hash, iden-tifiers of the originating DataWriter and destination DataReader, etc.The KeyHash submessage element may only appear in the Data and DataFrag submessages.Depending on the data-type associated with the DataWriter that wrote the data the KeyHash sub-message contains either:• A serialized representation of the values of all the attributes that are declared as ‘key’ attributes in the associated data-type• Or else a MD5 hash computed over the aforementioned serialized key attributes.Different RTPS Submessage within the same RTPS Message may originate on differentDataWriter or DataReader entities within the DomainParticipant that sent the RTPS Message.It is also possible for a single RTPS Message to combine submessages that originated on differentDDS DomainParticipant entities this is done by preceding the set of RTPS Submessages thatoriginate from a common DomainParticipant with an InfoSource RTPS submessage.7.2.2 Secure RTPS MessagesSection 7.1.1 identified the Threats addressed by the DDS Security Specification. Ito protect againstthe “Authorized Subscription” threat it is necessary use encryption to protect the sensitive parts ofthe RTPS message.Depending on the application requirements it may be that the only thing that should be kept confi-dential is the content of the application data, that is, the information contained in the “Serialized-Data” RTPS submessage element. However, other applications may also consider the informationon on other RTPS SubmessageElements (e.g. sequence numbers, KeyHash, and unique writer/readeridentifiers) to be confidential. So the entire Data (or DataFrag) submessage may need to be en-crypted. Similarly certain applications may consider other submessages such as Gap, AckNack,Heartbeat, HeartbeatFrag, etc. to also be confidential.For example, a Gap RTPS Submessage instructs a DataReader that a range of sequence num-bers is no longer relevant. If an attacker can modify or forge a Gap message from a DataWriterit can trick the DataReader into ignoring the data the DataWriter is sending.To protect against the “Unauthorised Publication” and the “Tampering and Replay” threats it is nec-essary that messages be signed using secure hashes or digital signatures. Depending on the applica-tion it may be sufficient to sign only the application data (SerializedData submessage element),the whole Submessage, and/or the whole RTPS Message.To support different deployment scenarios this specification uses a “message transformation”mechanism that gives the Security Plugin Implementations fine-grain control over which parts of theRTPS Message need to be encrypted and/or signed.The Message Transformation performed by the Security Plugins transforms an RTPS Message intoanother RTPS Message. The RTPS Header is preserved, however the remaining content in the14 DDS Security, Revised Submission
  26. 26. RTPS Message may be encrypted, protected by a Secure Message Authentication Code (MAC),and/or signed. The MAC and/or signature can also include the RTPS Header to protect its integrity.7.2.3 Platform Independent Description<NOTE: THIS SECTION IS STILL PRELIMINARY ANDINCOMPLETE>7.2.3.1 RTPS Secure Submessage Elements7.2.3.1.1 CryptoTransformIdentifier7.2.3.1.2 SecuredData7.2.3.1.3 EncodedPayload7.2.3.2 RTPS Secure SubmessagesThis specification introduces a new RTPS Submessages that will be used to wrap other submessagessecuring their content. The format of the these additional RTPS submessages complies with the for-mat of all RTPS submessages, consisting of an RTPS Submessage Header followed by a set of RTPSsubmessage elements.DDS Security, Revised Submission 15
  27. 27. 7.2.3.2.1 RTPS SecureSubMsg7.2.3.2.1.1 PurposeThis submessage is used to wrap one or more regular RTPS submessages in such a way that theircontents are secured via encryption, message authentication, and/or digital signatures.The Submessage conforms to the general structure of RTPS submessages and therefore can appearinside a well-formed RTPS message.7.2.3.2.1.2 ContentThe elements that form the structure of the RTPS SecureSubMsg are described in the table below. Element   Type   Meaning  EndianessFlag   SubmessageFlag   Appears  in  the  Submessage  header  flags.  Indicates   endianess.  16 DDS Security, Revised Submission
  28. 28. multisubmsgFlag   SubmessageFlag   Indicates  the  submessage  contains  potentially  multi-­‐ ple  submessages  withincryptoTransformId   CryptoTransformIdentifier   Identifies  the  kind  of  transformation  that  was  per-­‐ formed  in  the  message  and  provides  additional  in-­‐ formation  required  by  the  intended  recipients  to  de-­‐ code  and  verify  the  messagepayload   EncodedPayload   Contains  the  result  of  transforming  the  original  mes-­‐ sage.  Depending  on  the  plugin  implementation  may   contain  encrypted  content,  message  access  codes   and/or  digital  signatures7.2.3.2.1.3 ValidityThe Submessage is invalid if the submessageLength in the Submessage header is too small.7.2.3.2.1.4 Logical InterpretationThe SecureSubMsg provides a way to send secure content inside a legal RTPS submessage.A SecureSubMsg may wrap a single RTPS Submessage, or a collection of RTPS submessages.These two situations are distinguished by the value of the MultisubmsgFlag.If the MultisubmsgFlag is false, then the SecureSubMsg contains a single RTPS submessage.If the MultisubmsgFlag is true, then the SecureSubMsg may contain multiple RTPS submes-sages. Whether it does or not will be determined by information inside the cryptoTransformId.The specific mechanism depends on the encoding/transformation performed.7.2.4 Mapping to UDP/IP PSM<NOTE: THIS SECTION IS STILL PRELIMINARY ANDINCOMPLETE>7.2.4.1 RTPS Secure Submessage Elements7.2.4.1.1 CryptoTransformIdentifier7.2.4.1.2 EncodedPayload7.2.4.1.3 SecuredData7.2.4.2 RTPS Secure Submessages7.2.4.2.1 SecureSubMsg7.2.4.2.1.1 Wire representation7.2.4.2.1.2 Submessage IdThe SecureSubMsg shall have the submesageId set to the value 0x30.DDS Security, Revised Submission 17
  29. 29. 7.2.4.2.1.3 Flags in the Submessage Header8 Plug-in ArchitectureThere are five plugin SPIs- Authentication, Access-Control, Cryptographic, Logging, and Data Tag-ging.18 DDS Security, Revised Submission
  30. 30. The responsibilities and interactions between these Service Plugins are summarized in the table be-low and detailed in the sections that follow.Service Plugin Purpose InteractionsAuthentication Authenticate the principal that is The principal may be an applica-DDS Security, Revised Submission 19
  31. 31. joining a DDS Domain. tion/process or the user associated with that application or process. Support mutual authentication be- tween participants and establishment of a shared secret.Access Control Decide whether a principal is al- Protected operations include joining a lowed to perform a protected opera- specific DDS domain, creating a Topic, tion. reading a Topic, writing a Topic, etc.Cryptography Generate keys. Perform Key Ex- This plugin implements 4 complementary change. Perform the encryption and interfaces: CryptoKeyFactory, Crypto- decryption operations. Compute KeyExchange, and CryptoTransform. digests, compute and verify Message Authentication Codes. Sign and ver- ify signatures of messages.Logging Log all security relevant eventsData Tagging Add  a  data  tag  for  each  data  sample  8.1 Security ExceptionSecurityExceptionAttributescode SecurityExceptionCodemessage StringOperationsinit void exception SecurityExceptionget_message String exception SecurityExceptionget_code SecurityExceptionCode exception SecurityExceptionget_minor_code long exception SecurityException20 DDS Security, Revised Submission
  32. 32. SecurityException objects are potentially returned from many of the calls in the plugins. They areused to return an error code and message. Depending on the programming language used a Securi-tyException may map to a programming-language exception or an output parameter to the function.8.1.1 Operation: initThe operation  initializes  a  SecurityException.  Depending  on  the  programming  language  used,  this  function  may  be  automatically  provided  by  the  constructor,  or  it  may  need  to  be  ex-­‐plicitly  invoked.  8.1.2 Operation: get_messageThe  operation  returns  a  textual  message  associated  with  the  SecurityException, the mes-­‐sage  provides  a  description  of  the  exception  in  human-­‐readable  form.  8.1.3 Operation: get_codeThe  operation  returns  the  code  associated  with  the  exception.  8.1.4 Operation: get_minor_codeThe  operation  returns  a  plugin-­‐dependent  code  associated  with  the  exception.8.2 PropertyProperty is a data-type that holds a pair of strings. One is considered the property “name” and theother the property “value” associated that name. Property Sequences are used as a generic data-typeto configure the plugins, pass meta-data and provide an extensible mechanism for vendors to config-ure the behavior of their plugins without breaking portability or interoperability.Properties with names that start with the prefix “dds.security.” are reserved by this specifica-tion, including future versions of this specification. Plugin implementers can also use this mecha-nism to pass meta-data and configure the behavior of their plugins. In order to avoid collisions on thevalue of the “name” attribute implementers shall use property names that start with a prefix to anICANN domain name they own, in reverse order. For example the prefix would be “com.acme.” forplugins developed by a hypothetical vendor that owns the domain “acme.com”.The names and interpretation of the expected properties shall be specified by each Plugin implemen-tation.PropertyAttributesname Stringvalue StringDDS Security, Revised Submission 21
  33. 33. 8.3 CredentialCredentials provide a generic mechanism to pass information from DDS to the Security Plugins. Thisinformation is used to identify that application that is running and its permissions. The Credentialsdata-type provides a generic container for security credentials and certificates. The actual format andinterpretation of the credentials and how they are configured is specific to each implementation ofthe Security Plugins and shall be specified by each Security Plugin.Typical use of credentials would be signed certificates or signed permissions documents. Credentialsare only exchanged locally between the DDS implementation and the plugins linked to it and runningin the same process space. They are never sent between processes over network.The structure of Credentials is defined for all plugin implementations. However the contents and in-terpretation of the Credentials attributes shall be specified by each Plugin implementation.CredentialAttributescredential_classid Stringproperties Property[]value OctetSeqThere are several specializations of the Credential class. They all share the same format but are usedfor different purposes this is modeled by defining specialized classes.22 DDS Security, Revised Submission
  34. 34. 8.3.1 Attribute: credential_classidIdentifies the kind of credential.  Values of the credential_class_id with the prefix “dds.” are reserved for this specification, includ-ing future versions of the specification. Implementers of this specification can use this attribute toidentify non-standard Credentials. In order to avoid collisions the credential_class_id they use shallstart with a prefix to an ICANN domain name they own, using the same rules specified in Section 8.2for property names.8.3.2 Attribute: propertiesTis attribute is a container for meta-data to be held in the Credential. The contents are specific toeach plugin implementation.8.3.3 Attribute: valueThis attribute is used to hold the data stored in the Credential. The contents are specific to eachplugin implementation.8.4 TokenTokens provide a generic mechanism to pass information between Security Plugins using DDS as thetransport. Token objects are meant for transmission over the network using DDS either embeddedwithin the BuiltinTopicData sent via discovery or alternatively via special Topics defines by thisspecification.The structure of Tokens is defined for all plugin implementations. However the contents and inter-pretation of the Token attributes shall be specified by each Plugin implementation.TokenAttributestoken_classid Stringwrapper_classid Stringproperties Property[]value OctetSeqwrapped_value OctetSeqThere are multiple specializations of the Token class. They all share the same format but are used fordifferent purposes this is modeled by defining specialized classes.DDS Security, Revised Submission 23
  35. 35. 8.4.1 Attribute: token_classidIdentifies the kind of token.  Strings with the prefix “dds.security.” are reserved for this specification, including future ver-sions of the specification. Implementers of this specification can use this attribute to identify non-standard tokens. In order to avoid collisions the token_classid they use shall start with a prefixto an ICANN domain name they own, using the same rules specified in Section 8.2 for propertynames.8.4.2 Attribute: wrapper_classidIdentifies the kind of encryption used to protect the wrapped_value, if any.Strings with the prefix “dds.security.” are reserved for this specification, including future ver-sions of the specification. Implementers of this specification can use this attribute to identify non-standard token wrappers. In order to avoid collisions on the chosen string the wrapped_classidthey use shall start with a prefix to an ICANN domain name they own, using the same rules specifiedin Section 8.2 for property names.8.4.3 Attribute: propertiesThis attribute provides a container for meta-data to be held in the Token. The contents are specific toeach plugin implementation.24 DDS Security, Revised Submission
  36. 36. 8.4.4 Attribute: valueThis attribute is used to hold the data stored in the token. The contents are specific to each pluginimplementation. The value attribute is intended to store data in ‘cleartext’. To store encrypted orsigned data the plugin implementation should use the wrapped_value attribute instead.8.4.5 Attribute: wrapped_valueThis attribute is used to hold the data stored in the token. The contents are specific to each pluginimplementation. The value attribute is intended to store ‘cryptographically protected’ data. The kindof protection (e.g. encryption and/or signature) is indicated by the value of the wrapper_classidattribute.8.5 DDS support for plugin message exchangeIn order to perform mutual authentication and key exchange between DDS Participants the securityplugins associated with those participants need to exchange messages.DDS already has a mechanism for message exchange between the Participants. Exposing some ofthese facilities to the Security Plugins would greatly simplify the implementation of the plugins,which would be relieved from having to implement a separate messaging protocol.The DDS interoperability wire protocol specifies the existence of two built-in end points BuiltinPar-ticipantMessageWriter and BuiltinParticipantMessageReader (See section 9.6.2.1 of the DDSInteroperability Protocol).These endpoints were designed to be extensible and support the kind of message-exchanged neededby the security plugins.The messages exchanged by the BuiltinParticipantMessageWriter have the associated type Partici-pantMessageData. This type is as defined by the DDS Interoperability Wire Protocol version 2.1)and can be represented in IDL as:typedef octet GuidPrefix_t[12];typedef octet ParticipantMessageDataKind[4];struct ParticipantMessageData { GuidPrefix_t participantGuidPrefix; //@Key ParticipantMessageDataKind kind; //@Key sequence<octet> data;};The Interoperability Wire Protocol furthermore states that the messages sent by the BuiltinPartici-pantMessageWriter shall always set the participantGuidPrefix to the GUID prefix of the originatingparticipant.The ‘kind’ attribute is used to identify of different types of messages. The actual data is carried onthe ‘value’ octet sequence. Its content and format is specified for each value of the ‘kind’ attribute.DDS Security, Revised Submission 25
  37. 37. 8.5.1 Reserved values of ParticipantMessageDataKindThis specification, including future versions of this specification reserves ParticipantMes-sageDataKind values in the range 0x00010000 to 0x0001FFFF, both included.Within the above range, the range 0x00018000 to 0x0001FFFF is reserved for vendor-specific exten-sions and shall not be used by this specification, including future versions of this specification.The specification defines the following values for the ParticipantMessageDataKind:#define KIND_SECURITY_AUTH_HANDSHAKE {0x00, 0x01, 0x00, 0x01}#define KIND_SECURITY_PARTICIPANT_CRYPTO_TOKENS {0x00, 0x01, 0x00, 0x02}#define KIND_SECURITY_DATAWRITER_CRYPTO_TOKENS {0x00, 0x01, 0x00, 0x03}#define KIND_SECURITY_DATAREADER_CRYPTO_TOKENS {0x00, 0x01, 0x00, 0x04}Additional values of the ParticipantMessageDataKind may be defined with each plugin implemen-tation.8.5.2 Format of data within ParticipantMessageDataEach value for the kind in ParticipantMessageData uses different schema to store data within thedata (octet sequence) attribute in the ParticipantMessageData.8.5.2.1 Data for message kind KIND_SECURITY_AUTH_HANDSHAKEIf ParticipantMessageData kind is KIND_SECURITY_AUTH_HANDSHAKE the data attributecontains the CDR big-endian serialization of the structure MessageToken defined by the IDL below:struct Property { string<> name; string<> value;};struct Token { string<> token_classid; string<> wrapper_classid; sequence<Property> properties; sequence<octet> value;};struct MessageToken : Token {};struct CryptoToken : Token {};8.5.2.2 Data for message kind KIND_SECURITY_PARTICIPANT_CRYPTO_TOKENSIf ParticipantMessageData kind is KIND_SECURITY_PARTICIPANT_CRYPTO_TOKENS the data attribute contains the CDR big-endian serialization of thestructure ParticipantCryptoTokenSMsg defined by the IDL below:struct ParcicipantCryptoTokensMsg {26 DDS Security, Revised Submission
  38. 38. octet sending_participant_guid[16]; octet receiving_participant_guid[16]; sequence<CryptoToken> crypto_tokens;};8.5.2.3 Data for message kind KIND_SECURITY_DATAWRITER_CRYPTO_TOKENSIf ParticipantMessageData kind is KIND_SECURITY_DATAWRITER_CRYPTO_TOKENS the data attribute contains the CDR big-endian serialization of thestructure DatawriterCryptoTokensMsg defined by the IDL below:struct DatawriterCryptoTokensMsg { octet datawriter_guid[16]; octet readerwriter_guid[16]; sequence<CryptoToken> crypto_tokens;};8.5.2.4 Data for message kind KIND_SECURITY_DATAREADER_CRYPTO_TOKENSIf ParticipantMessageData kind is KIND_SECURITY_DATAWRITER_CRYPTO_TOKENS the data attribute contains the CDR big-endian serialization of thestructure DatareaderCryptoTokensMsg defined by the IDL below:struct DatareaderCryptoTokensMsg { octet readerwriter_guid[16]; octet datawriter_guid[16]; sequence<CryptoToken> crypto_tokens;};8.6 Authentication Plug-inThe Authentication Plug-in SPI defines the types and operations necessary to support the authentica-tion of DDS DomainParticipants.8.6.1 Background (Non-Normative)Without the security enhancements, any DDS DomainParticipant is allowed to join a DDSDomain without authenticating. However, in the case of a secure DDS system, every DDS partici-pant will be required to authenticate to avoid data contamination from unauthenticated participants.The DDS protocol detects when participants enter the network through its native discovery mecha-nism.The discovery mechanism that registers participants with the DDS middleware is enhanced with anauthentication protocol. A participant that enables the authentication plug-in will only communicateto another participant that has the authentication plug-in enabled.The plugin SPI is designed to support multiple implementations which may require varying numbersof message exchanges, which may be used to challenge the other side so it can determine it knowsthe secrets, associated with its credential, and potentially establish shared secrets, which can then beused to exchange session keys.DDS Security, Revised Submission 27
  39. 39. 8.6.2 Authentication Plug-in ModelThe Authentication Plug-in model is presented in the figure below.8.6.2.1 IdentityCredentialThis is a native type that represents the information that is passed from the DDS middleware to theplugin in order to prove identity of the application that contains the DomainParticipant. Thestructure and interpretation of the contents as well as the mechanism used to pass it to theAuthenticationPlugin shall be specified by each plugin implementation.28 DDS Security, Revised Submission
  40. 40. 8.6.2.2 IdentityTokenAn IdentityToken encodes the identity information for a DomainParticipant, in a mannerthat can be externalized and propagated via discovery.8.6.2.3 IdentityHandleAn IdentityHandle is an opaque local reference to internal state within theAuthenticationPlugin, which uniquely identifies a DomainParticipant. It is under-stood only by the AuthenticationPlugin and references the authentication state of the Partici-pant. This object is returned by the AuthenticationPlugin as part of the validation of theidentity of a DomainParticipant and is used whenever a client of theAuthenticationPlugin needs to refer to the identity of a previously identifiedDomainParticipant.8.6.2.4 HandshakeHandleA HandshakeHandle is an opaque local reference used to refer to the internal state of a possiblemutual authentication or handshake protocol.8.6.2.5 MessageTokenA MessageToken encodes plugin-specific information that the Authentication plugins associatedwith two DomainParticipant entities exchange as part of the mutual authentication handshake. TheMessageToken are understood only by the AuthenticationPlugin implementations on ei-ther side of the handshake. The MessageToken are sent and received by the DDS implementationunder the direction of the AuthenticationPlugins.8.6.2.6 SharedSecretHandleA SharedSecretHandle is an opaque local reference to internal state within theAuthenticationPlugin containing a secret that is shared between theAuthenticationPlugin implementation and the peer AuthenticationPlugin implemen-tation associated with a remote DomainParticipant. It is understood only by the twoAuthenticationPlugin implementations that share the secret. The shared secret is used to en-code Tokens, such as the CryptoToken, such that they can be exchanged between the twoDomainParticipants in a secure manner.8.6.2.7 AuthenticationThis interface is the starting point for all the security mechanisms. When a DomainParticipantis either locally created or discovered, it needs to be authenticated in order to be able to communicatein a DDS Domain.The interaction between the DDS implementation and the Authentication plugins has been designedin a flexible manner so it is possible to support various authentication mechanisms, including thoseDDS Security, Revised Submission 29
  41. 41. that require a handshake and/or perform mutual authentication between participants and establishes ashared secret. This interaction is described in the state machine illustrated in the figure below.AuthenticationNo AttributesOperationsvalidate_local_ident ValidationResult_tity out: IdentityHandle30 DDS Security, Revised Submission
  42. 42. local_identity_handle credential IdentityCredential participant_key Octet[16] exception SecurityExceptionget_identity_token IdentityToken handle IdentityHandle exception SecurityExceptionvalidate_remote_iden ValidationResult_ttity out: IdentityHandle remote_identity_handle local_identity_handle IdentityHandle remote_identity_token IdentityToken remote_participant_key Octet[16] exception SecurityExceptionbegin_handshake_requ ValidationResult_test out: handshake_handle HandshakeHandle out: handshake_message MessageToken initiator_identity_handl IdentityHandle e replier_identity_handle IdentityHandle exception SecurityExceptionbegin_handshake_repl ValidationResult_ty out: handshake_handle HandshakeHandle out: MessageToken handshake_message_out handshake_message_in MessageToken initiator_identity_handl IdentityHandle e replier_identity_handle IdentityHandle exception SecurityExceptionprocess_handshake ValidationResult_tDDS Security, Revised Submission 31
  43. 43. out: MessageToken handshake_message_out handshake_message_in MessageToken handshake_handle HandshakeHandle exception SecurityExceptionget_shared_secret SharedSecretHandle handshake_handle HandshakeHandle exception SecurityExceptionset_listener Boolean listener AuthenticationListen er exception SecurityExceptionreturn_token Boolean token IdentityToken exception SecurityExceptionreturn_handshake_han Booleandle handshake_handle HandshakeHandle exception SecurityExceptionreturn_identity_hand Booleanle identity_handle IdentityHandle exception SecurityExceptionreturn_sharedsecret_ Booleanhandle sharedsecret_handle SharedSecretßHandle exception SecurityException8.6.2.7.1 Type: ValidationResult_tEnumerates the possible return values of the validate_local_identity and validate_remote_identityoperations.ValidationResult_tVALIDATION_OK Indicates the validation has succeeded32 DDS Security, Revised Submission
  44. 44. VALIDATION_FAILED Indicates the validation has failedVALIDATION_PENDING_RETRY Indicates that validation is still proceeding. The operation shall be retried at a later point in time.VALIDATION_PENDING_HANDSHAKE_REQUEST Indicates that validation of the submitted IdentityToken requires sending a handshake message. The DDS Implementation shall call the operation begin_handshake_request and send the MessageToken obtained from this call using the BuiltinParticipantMessageWriter.VALIDATION_PENDING_HANDSHAKE_MESSAGE Indicates that validation is still pending. The DDS Implementation shall wait for a message on the BuiltinParticipantMessageReader and once this is received call process_handshake passing the infrmation received in that message.VALIDATION_OK_FINAL_MESSAGE Indicates that validation has succeeded but the DDS Implementation shall send a final message using the Builtin- ParticipantMessageWriter.8.6.2.7.2 Operation: validate_local_identityValidates the identity of the local DomainParticipant, provided by anIdentityCredential. The operation returns as an output parameter the IdentityHandle,which can be used to locally identify the local Participant to the AuthenticationPlugin.If an error occurs, this method shall return VALIDATION_FAILED.The method shall return either VALIDATION_OK if the validation succeeds, or VALIDA-TION_FAILED if it fails, or VALIDATION_PENDING_RETRY if the verification has not finished.If VALIDATION_PENDING_RETRY is been returned, the operation shall be called again after aconfigurable delay to check the status of verification. This shall continue until the operation returnsDDS Security, Revised Submission 33
  45. 45. either VALIDATION_OK if the validation succeeds, or VALIDATION_FAILED. This approachallows non-blocking interactions with services whose verification may require invoking remote serv-ices.Parameter local_identity_handle: A handle that can be used to locally refer to the AuthenticatedParticipant in subsequent interactions with the AuthenticationPlugin. The nature of the han-dle is specific to each AuthenticationPlugin implementation. The handle will only be mean-ingful if the operation returns VALIDATION_OK.Parameter credential: A credential that the AuthenticationPlugin implementation may use to vali-date the identity of the local DomainParticipant. The nature and configuration of the credentialis specific to each AuthenticationPlugin implementation.Parameter exception: A SecurityException object.Return: The operation shall return • VALIDATION_OK if the validation was successful • VALIDATION_FAILED if it failed. • VALIDATION_PENDING_RETRY if verification has not completed, and the operation should be retried later.8.6.2.7.3 Operation: validate_remote_identityInitiates the process of validating the identity of the discovered remote DomainParticipant,represented as an IdentityToken object. The operation returns the ValidationResult_tindicating whether the validation succeeded, failed, or is pending a handshake. If the validation suc-ceeds, an IdentityHandle object is returned which can be used to locally identify the remoteDomainParticipant to the AuthenticationPlugin.If the validation can be performed solely with the information passed and it succeeds the operationshall return VALIDATION_OK. If it can be performed with the information passed and it fails itshall return VALIDATION_FAILED.The validation of a remote participant might require the remote participant to perform a handshake.In this situation the validate_remote_identity operation shall return VALIDA-TION_PENDING_HANDSHAKE_REQUEST or VALIDA-TION_PENDING_HANDSHAKE_MESSAGE.If the operation returns VALIDATION_PENDING_HANDSHAKE_REQUEST, then the DDS im-plementation shall call the operation begin_handshake_request to continue the validationprocess.If the operation returns VALIDATION_PENDING_HANDSHAKE_MESSAGE, then the DDS im-plementation shall wait until it receives a handshake message from the remote participant identifiedby the remote_participant_key. This message is received on the BuiltinParticipantMessageReaderand shall contain a participantGuidPrefix matching the remote_participant_key and a kind match-ing KIND_SECURITY_AUTH_HANDSHAKE.Upon receiving the above ParticipantMessageData message the DDS implementation shall interpretthe bytes inside the ParticipantMessageData data sequence as the CDR serialization of aMessageToken and shall call the operation begin_handshake_reply passing the received34 DDS Security, Revised Submission
  46. 46. MessageToken and shall call the operation begin_handshake_reply passing the receivedMessageToken as the handshake_message_in.If an error occurs, this method shall throw an exception.Parameter remote_identity_token : A token received as part ofParticipantBuiltinTopicData representing the identity of the remoteDomainParticipant.Parameter local_identity_handle: A handle to the local DomainParticipant that is requestingthe remote participant to be validated. The local handle must have been obtained by an earlier call tovalidate_local_identity.Parameter (out) remote_identity_handle: A handle that can be used to locally refer to the remoteAuthenticated Participant in subsequent interactions with the AuthenticationPlugin. The na-ture of the remote_identity_handle is specific to each AuthenticationPlugin implementa-tion. The handle will only be provided if the operation returns something other than VALIDA-TION_FAILED.Parameter exception: A SecurityException object.Return: The operation shall return: • VALIDATION_OK if the validation was successful, • VALIDATION_FAILED if it failed, • VALIDATION_PENDING_HANDSHAKE_REQUEST if validation has not completed and the DDS implementation shall call begin_handshake_request, to continue the valida- tion. • VALIDATION_PENDING_HANDSHAKE_MESSAGE if validation has not completed and the DDS implementation shall wait for a message on the BuiltinParticipantMessageReader with the participantGuidPrefix matching the remote_participant_key and a kind matching KIND_SECURITY_AUTH_HANDSHAKE and then call the operation begin_handshake_reply, to continue the validation. • VALIDATION_PENDING RETRY if the validation has not completed and the operation should be called again at a later point in time to check the status of validation.8.6.2.7.4 Operation: begin_handshake_requestThis operation is used to initiate a handshake when the first handshake message must be generated. Itshall be called by the DDS middleware solely as a result of having a previous call to vali-date_remote_identity returns VALIDATION_PENDING_HANDSHAKE_REQUEST.This operation returns a MessageToken that shall be used to send a handshake to the remote partici-pant identified by the replier_identity_handle.The contents of the MessageToken are specified by the plugin implementation.If an error occurs, this method shall throw an exception.Parameter (out) handshake_handle: A handle returned by the Authentication Plugin used keep thestate of the handshake. It is passed to other operations in the PluginDDS Security, Revised Submission 35
  47. 47. Parameter (out) handshake_message: A Token containing a message to be sent using the Builtin-ParticipantMessageWriter. The contents shall be specified by each plugin implementation.Parameter initiator_identity_handle: Handle to the local participant that originated the handshake.Parameter replier_identity_handle: Handle to the remote participant whose identity is being vali-dated.Parameter exception: A SecurityException object.Return: The operation shall return: • VALIDATION_OK if the validation was successful, • VALIDATION_FAILED if it failed, • VALIDATION_PENDING_HANDSHAKE_MESSAGE if validation has not completed and the DDS implementation shall send the handshake_message_out using the BuiltinPartici- pantMessageWriter and then wait for a message on the BuiltinParticipantMessageReader with the participantGuidPrefix matching the remote_participant_key and a kind matching KIND_SECURITY_AUTH_HANDSHAKE and then call the operation begin_handshake_reply, to continue the validation. • VALIDATION_OK_FINAL_MESSAGE if the validation succeeded but the DDS implemen- tation shall send the returned handshake_message using the BuiltinParticipantMes- sageReader. • VALIDATION_PENDING RETRY if the validation has not completed and the operation should be called again at a later point in time to check the status of validation.8.6.2.7.5 Operation: begin_handshake_replyThis operation is used to initiate a handshake when an initial handshake message has been receivedfrom another participant. It shall be called by the DDS middleware solely as a result of having a pre-vious call to validate_remote_identity returns VALIDA-TION_PENDING_HANDSHAKE_MESSAGE and having also received a message on the Builtin-ParticipantMessageReader with the participantGuidPrefix matching the GUID prefix of the par-ticipant associated with the initiator_identity_handle and a kind matchingKIND_SECURITY_AUTH_HANDSHAKE.This operation generates a handshake_message_out in response to a received hand-shake_message_in. Depending on the return value of the function the DDS implementation shallsend the handshake_message_out using the BuiltinParticipantMessageWrite to the participantidentified by the initiator_identity_handle.The contents of the handshake_message_out MessageToken are specified by the plugin implemen-tation.If an error occurs, this method shall throw an exception.Parameter (out) handshake_handle: A handle returned by the Authentication Plugin used keep thestate of the handshake. It is passed to other operations in the PluginParameter (out) handshake_message_out: A Token containing a message to be sent using theBuiltinParticipantMessageWriter. The contents shall be specified by each plugin implementation.36 DDS Security, Revised Submission

×