Keywords: Web Services Security, Interoperability, WS-I Basic Security Profile
Biography
Paula is a member of the Security and Privacy Department at IBM T.J. Watson Research. She is currently working on Web Services Security. She is an active member of OASIS Web Services Security TC, OASIS Security Services TC, and WS-I Basic Security Profile Working Group.
Biography
Michael is a member of the Security and Privacy Department at the IBM T.J Watson Research Center. He is currently working on Web Services Security. He is an editor of the WS-I Basic Security Profile, and is an active member of OASIS Web Services Security, Security Services, eXtensible Access Control Markup Language and Digital Signature Services Technical Committees.
Biography
Tony is the chief security architect for Tivoli. As Distinguished Engineer, he is responsible for security infrastructure design and development across IBM, Tivoli and Lotus. Tony served as the primary security liaison to Sun Microsystems' JavaSoft Division for Java security design and development collaboration. In his 20-year career with IBM, he has covered the following positions, Lead Security architect for VM/SP, and Security architect for AS/400, Security architect for OS/2. Tony has authored and co-authored over thirty technical journal and conference articles. He has published a book on Java Security and the Internet. He has been on the technical committee of three major scientific journals and one conference, and has reviewed extensively work published by peers in the field. Tony made presentations and gave invited speeches at numerous technical security conferences.
Enterprises are adopting Web Services to ease application integration across heterogeneous environments within and across security domain boundaries. Security is an important element for the adoption of Web Services. The Organization for the Advancement of Structured Information Standards (OASIS) has recently ratified the Web Services Security standards (Web Services Security: SOAP Message Security 1.0 (WS-Security 2004 [WSSCore]), Web Services Security: UsernameToken Profile 1.0 [WSSUTP], and Web Services Security: X.509 Certificate Token Profile [WSSX509]) to provide an extensible framework for providing message integrity, confidentiality, identity propagation, and authentication. The Web Services Interoperability Organization (WS-I) is profiling standards to provide guidelines for implementation and use of relevant standards to enhance interoperability. This paper describes the activities of the WS-I Basic Security Profile (BSP) Working Group (WG). This Working Group is chartered to improve interoperability of security technologies for Web Services by profiling the OASIS Web Service Security and HTTP Over TLS [RFC2818] standards. This interoperability profile (known as the Basic Security Profile 1.0) [BSP] is an extension of the WS-I Basic Profile [BP11]. The WS-I Basic Profile addresses interoperability for implementations of core Web Services standards.
1. Introduction
2. Overview of WS-I
3. Security Scenarios
4. Basic Security Profile
5. Summary
Acknowledgements
Bibliography
Enterprises are adopting Web Services to ease application integration across heterogeneous environments within and across domain boundaries. Security technologies used with Web Services must instill confidence in enterprise security architects that resources will not be exposed to unauthorized use. Technologies must integrate with and leverage existing security infrastructure. Web Services Security and HTTP Over TLS provide extensible and flexible mechanisms which suit these purposes well. However, this same extensibility and flexibility combine to make interoperability difficult. Some set of guidelines are needed in order to limit the variety of possibilities that applications must implement and test in order to interoperate.
The Web Services Interoperability Organization (WS-I) is an open industry organization committed to promoting interoperability of Web Services, based on common industry-accepted specifications. The WS-I promotes interoperability by providing guidance and making recommendations for Web services implementations across platforms, applications, and programming languages. Through these recommendations they hope to lower the technical obstacles to adoption of Web Services technologies and ensure the continued evolution of Web Services technologies. More information on the mission of the WS-I and its membership is available at the web site http://www.ws-i.org.
The WS-I working groups produce the following types of deliverables for enhancing interoperability:
All working groups must coordinate their efforts to make sure that related use cases, usage scenarios, profiles, sample applications, and testing tools are delivered together providing a complete package for improving interoperability. The rest of this paper focuses on the Basic Security Profile Working Group and its deliverables, namely the Security Scenarios document and the Basic Security Profile. Both of these documents are in public Working Group Draft status. The documents are not final but the WS-I board has approved these documents for public review which provides valuable feedback to the BSP Working Group.
The Security Scenarios [SecScen], currently available as a public Working Group Draft, was created to guide the creation of the Basic Security Profile. The scenarios are targeted to Web Services architects and developers and explain how security applies to the Usage Scenarios defined for the Basic Profile. The document identifies security challenges and threats and identifies technologies to address the security challenges along with countermeasures to mitigate the threats. The document also identifies some security challenges and threats that are outside the scope of the BSP WG at this time.
The following 3 basic message exchange patterns (MEPs) are adapted from the scenarios defined for the Basic Profile:
The description of security threats and solutions for these scenarios provides insight to understanding the conformance requirements and security considerations for the BSP. The threats that are addressed include message alteration, loss of confidentiality, falsified messages, man in the middle, principal spoofing, forged claims, denial of service and replay of parts or all of the message.
SOAP messages are sent from an initial SOAP sender to an ultimate SOAP receiver along a SOAP message path consisting of zero or more SOAP intermediaries that process and potential transform the SOAP message. A challenge is to preserve security properties of the SOAP message from the initial SOAP sender to the ultimate SOAP receiver. Transport layer security mechanisms such as HTTP Over TLS may be used to secure messages between two adjacent SOAP nodes whereas message layer security mechanisms defined in the Web Services Security standard must be used in the presence of intermediaries (see Figure1) or when data origin authentication is required.
Security headers may contain Security Tokens, Security Token References, Timestamps, Nonces, Signatures, Encrypted Keys and Encrypted Data. Each security header is targeted to a specific SOAP actor. A SOAP message may contain multiple security headers, however each must be targeted to a different SOAP actor. Each security header may contain multiple Security Tokens, Security Token References, Nonces, Signatures, Encrypted Keys and Encrypted Data; however there may be at most one Timestamp.
SOAP messages are composed of xml elements. Elements may be signed and/or encrypted by being referenced from a Signature or a Reference List within an Encrypted Key. Individual elements within a message may be referenced from multiple Signatures and/or Reference Lists and messages may be composed of signed and/or encrypted elements from other messages. As intermediaries process messages, they potentially sign and encrypt new and pre-existing data, as well as consume signed and encrypted data targeted at a SOAP actor that they portray. It is important to preserve the security context of the message as it undergoes these transformations.
The Security Scenarios document discusses the challenges of data integrity, data confidentiality, peer authentication and data origin authentication in the context of both transport and message level security and describes how the mechanisms available can be used alone or in combination to secure messages. It is important for architects and developers to understand that combining security mechanisms may not result in a more secure solution but may introduce vulnerabilities that were not present previously.
The Basic Security Profile (BSP) provides clarifications and amplifications to a set of standards available to secure the transmission of web services messages. The BSP extends the profiles created by the WS-I Basic Profile Working Group adding interoperability guidelines for security. These profiles include:
The interoperability guidelines are created by adding constraints to existing standards. The following standards are profiled by the BSP:
The current versions of all draft documents can be found at the OASIS Web Services Security Technical Committee web site: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.
Additionally, each of these standards builds on existing standards such as XML Encryption, XML Signature, HTTP, TLS, XML Canonicalization, etc. bringing them into scope for the profile. These standards are only in scope where used by the higher level standards.
The completion of the BSP depends on the completion of the OASIS WSS: SOAP With Attachments Profile. This profile is being developed by the OASIS Web Services Security TC at the request of the BSP WG. The completion of the BSP also depends on the WS-I Sample Applications and the Test Tools Working Groups whose deliverables along with the BSP provide a complete package for improving interoperability.
The framework defined in these standards is extensible and can accommodate a wide range of security models, security tokens, signature formats and encryption technologies. The flexibility and extensibility of the framework however is a challenge for interoperability. The BSP focuses on improving interoperability by strengthening requirements when possible (making SHOULDs into MUSTs), reducing some of the flexibility (picking one right way when there are several alternatives) and extensibility. This limits the set of common functionality that vendors must implement and test for interoperability.
The guiding principles enumerated in the BSP declare that the profile should “do no harm”, make statements that are testable when possible, and focus on interoperability. The profile should not try to address any issues in the profiled standards that do not affect interoperability and enhancing interoperability should not create new security threats.
The profile includes requirement statements about two kinds of artifacts; SECURE_ENVELOPE and SECURE_MESSAGE. A SECURE_ENVELOPE is a SOAP envelope that has been subjected to integrity and/or confidentiality protection. A SECURE_MESSAGE expands the scope of the SECURE_ENVELOPE to include protocol elements transmitted with the SECURE_ENVELOPE that have been subject to integrity and/or confidentiality protection.
In order to conform to the BSP, any artifact that contains a construct that is addressed in the profile must conform to any statements that constrain its use. Conformant receivers are not required to accept all possible conformant messages. Conformance applies to deployed instances of services. Since major portions of the BSP may or may not apply in certain circumstances, individual URIs may be used to indicate conformance to parts of the BSP including the core profile or additional sections of the BSP for username token, X.509 token, and SOAP attachments. Additional URIs will be used as additional Token Profiles created by the OASIS WSS TC are profiled for interoperability by the BSP WG (e.g. SAML, REL and Kerberos).
The BSP includes statements that are interoperability requirements as well as statements that are security considerations. The normative requirement statements are identified by numbers prefixed with the letter ‘R’, i.e. R1234. These statements contain one requirement level keyword (i.e. “MUST”) and one conformance target (i.e. “SECURE_ENVELOPE”). For each group of related statements there are examples to demonstrate correct and incorrect use of the constructs that are addressed. The following is an example statement from the BSP which specifies an interoperability requirement along with examples:
R5420 Any ds:DigestMethod/@Algorithm element in a SECURE_ENVELOPE MUST have the value "http://www.w3.org/2000/09/xmldsig#sha1"
INCORRECT:
<ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#md5' />
CORRECT:
<ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
Certain statements are considered clarifying. Their intent is to eliminate confusion about the intended interpretation of a requirement from an underlying specification. Clarifying requirements are identified by adding a suffix of a subscript letter ‘c’, i.e. R1234c. The following is an example from the BSP:
R3060c A wsse:Embedded element in a SECURE_ENVELOPE MUST contain a single child element for a security token from an appropriate token profile.
The non-normative consideration statements are also identified by numbers prefixed by the letter ‘C’, i.e. C2345. The following is an example from the BSP:
C4210 A wsse:UsernameToken in a SECURE_ENVELOPE which contains a wsse:Nonce element SHOULD be referenced by a ds:Reference in a ds:SignedInfo element in order to prevent replay.
The security consideration statements provide guidance that is not strictly interoperability related but are testable best practices for security. It was considered valuable to include these so the testing tools might flag potentially insecure practices. It is not feasible to provide a comprehensive list of security considerations and not all security considerations can easily be converted into testable statements. A complete security analysis MUST be conducted on specific solutions based on the BSP and underlying standards.
The statements are listed in sections based on the standards being profiled. The sections include TLS, SOAP message security (covering usage of Security Tokens, SecurityTokenReferences and Timestamps), Username Token Profile, X.509 Certificate Token Profile, XML Signature and XML Encryption, Basic Profile and Attachment security.
Even a fully standards compliant application may not interoperate with another when the set of functionality supported is disjoint. For example, while a sender may encrypt using one of three specific algorithms prescribed by the BSP, a receiver may expect a different one of the three. Certain agreements must be made using mechanisms which are currently out of scope for the Profile. In the future standards will become available for describing these service policies and these will be subsequently profiled.
Enhanced interoperability for secure web services will be achieved through conformance to the Basic Security Profile. Vendors have already experienced enhanced interoperability for core web services through conformance to the Basic Profile. The Basic Security Profile is available today as a public working group draft. Preliminary testing of draft BSP-based sample applications has benefited the interoperability of products currently under development.
The Basic Security Profile Working Group welcomes comments from the public on the Security Scenarios and Basic Security Profile. Comments should be sent to wsi_secprofile_comment@lists.ws-i.org.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.