Enabling Interoperable Secure Web Services Bret Hartman, DataPower Technology July, 2004

2 THE CONTEXT  Businesses need to innovate at an ever increasing pace  Success requires broad interoperability  Within an enterprise  Between business partners  Across a heterogeneous set of platforms, applications and programming languages  Internet technologies are assumed, interoperability is required

3 THE CONTEXT  The shift to Web services is underway  An Internet-native distributed computing model based on XML standards has emerged  Early implementations are solving problems today and generating new requirements  The Web services standards stack is increasing in size and complexity to meet these requirements  The fundamental characteristic of Web services is interoperability

4 WHAT IS NEEDED?  Guidance  A common definition for Web services  Implementation guidance and support for Web services adoption  Interoperability  Across platforms, applications, and languages  Consistent, reliable interoperability between Web services technologies from multiple vendors  A standards integrator to help Web services advance in a structured, coherent manner

5 ABOUT WS-I  An open industry effort chartered to promote Web Services interoperability across platforms, applications and programming languages.  A standards integrator to help Web services advance in a structured, coherent manner  Approximately 150 member organizations  70% vendors, 30% end-user organizations  80% North America with active worldwide membership

6 WS-I GOALS Achieve Web services interoperability  Integrate specifications  Promote consistent implementations  Provide a visible representation of conformance  Accelerate Web services deployment  Offer implementation guidance and best practices  Deliver tools and sample applications  Provide a implementer’s forum where developers can collaborate  Encourage Web services adoption  Build industry consensus to reduce early adopter risks  Provide a forum for end users to communicate requirements  Raise awareness of customer business requirements

7 WORKING GROUPS  Basic Profile  Addresses the core set of specifications (e.g., SOAP, WSDL, UDDI, attachments, etc.) that provide the foundation for Web services  Basic Security Profile (New!)  Addresses transport security, SOAP messaging security, and other security considerations  Requirements Gathering  Captures business requirements to drive future profile selection  Sample Applications  Illustrate best practices for implementations on multiple vendor platforms  Testing Tools and Materials  Develops self-administered tests to very conformance with WS-I profiles

8 WS-I, STANDARDS AND INDUSTRY Businesses, Industry Consortia, Developers, End Users Implementation Guidance Standards Specifications Requirements

9 MILESTONES  Basic Profile 1.0 Package  Delivered Basic Profile 1.0, and associated sample applications and test tools as Final Material  More than 200 interoperability issues resolved in Basic Profile 1.0  Conventions around messaging, description and discovery  Vendors are incorporating the Basic Profile 1.0 into products and services  End-users are requiring conformance

10 CURRENT WORK: BASIC PROFILES  Basic Profile 1.1  Derived from the Basic Profile 1.0 incorporating any errata to date and separating out requirements related to the serialization of envelopes and their representation in messages  Attachments Profile 1.0  Complements Basic Profile 1.1 to add support for interoperable SOAP messages with attachments  Simple SOAP Binding Profile 1.0  Derived from those Basic Profile 1.0 requirements related to the serialization of the envelope and its representation in the message, incorporating any errata to date  Board Approval Drafts of these profiles were delivered June 3

11 CURRENT WORK: BASIC SECURITY PROFILE  Security Scenarios  Identifies security challenges and threats in building interoperable Web services and countermeasures for these risks  Basic Security Profile  Addresses transport security, SOAP messaging security and other security considerations  References existing specifications used to provide security, including the OASIS Web Services Security 1.0 specification  HTTP over TLS  SOAP with Attachments  WS-Security with Username and X.509 token profiles  SAML Token Profile and REL (XRML) Token Profile are being considered

12 SECURITY SCENARIOS WORKING DRAFT  Addresses  Security Challenges  Threats  Security Solutions and Mechanisms  Scenarios  February, 2004 draft for public comment  WGD.pdf WGD.pdf  Final Security Scenarios expected in August, 2004

13 SECURITY CHALLENGES  Peer Identification and Authentication  Data Origin Identification and Authentication  Data Integrity  Transport Data Integrity  SOAP Message Integrity  Data Confidentiality  Transport Data Confidentiality  SOAP Message Confidentiality  Message Uniqueness  Out of Scope  Credentials Issuance

14 THREATS  Message alteration  Attachment alteration  Confidentiality  Falsified messages  Man in the middle  Principal spoofing  Repudiation  Forged claims  Replay of message parts  Replay  Denial of service - amplifier

15 SECURITY SOLUTIONS AND MECHANISMS  Integrity, confidentiality, authentication, attributes  Transport layer (HTTP/HTTPS)  HTTP and SSL/TLS mechanisms  Message layer  WSS mechanisms  Securing SOAP with Attachments  Combinations  Large number of theoretically possible combinations  Identified nine believed to be of practical utility  Security considerations  Properties, threats addressed, limitations

16 SCENARIOS  Generic requirements  Peer authentication  Integrity  Confidentiality  Origin authentication  Scenario descriptions  One-way  Synchronous request / response  Basic callback  Others?

17 WS-I BASIC SECURITY PROFILE (BSP) 1.0  Methodology  Reviewed WSS Documents (WSS core, username, X.509)  Comments to WSS TC  Generated potential profiling points (captured as issues)  Reviewed underlying documents  IETF RFCs covering TLS  XML Signature, XML Encryption  Identified 90+ potential profiling points by looking for anything other than MUST (e.g. options in specifications)  Many have since been dropped  First public Working Draft published May, 2004   Final BSP expected in September, 2004

18 BSP 1.0 QUESTIONS AND ANSWERS  Cover SSL?  Yes, mentioned in WS-I Basic Profile 1.0  Address SOAP intermediaries?  Yes, must be considered because of security implications  What will document look like?  Identify constraints by category, as in Basic Profile  If and how to handle security considerations?  Added security considerations section even though it is not testable  One profile or several?  BSP 1.0 will be one document  Subsequent token profiles can be published separately  How to secure Attachment Profile 1.0?  Decided to use WSS and to request OASIS TC to do this work

19 EXAMPLE REQUIREMENT 4. Transport Layer Security This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:  HTTP over TLS Extensibility points: HTTP over TLS  E Ciphersuites - Additional ciphersuites may be specified. 4.1 SSL and TLS The following specifications (or sections thereof) are referred to in this section of the Profile; HTTP over TLS: Section SSL and TLS are both used as underlying protocols for HTTP/S. This profile places the following constraints on those protocols: Use of SSL 2.0 SSL 2.0 has known security issues and all current implementations of HTTP/S support more recent protocols. Therefore this profile prohibits use of SSL 2.0. R2001 A SENDER MUST NOT use SSL 2.0 as the underlying protocol for HTTP/S R2002 A RECEIVER MUST NOT use SSL 2.0 as the underlying protocol for HTTP/S

20 OTHER BSP 1.0 DELIVERABLES usage scenarios sample applications scenarios and sample applications use cases web services basic security profile testing tools other test materials testing tools and materials profile

21 TESTING AND DEMONSTRATING BSP 1.0  How to test Basic Security Profile 1.0?  Basic Profile 1.0 testing tools used a man in the middle testing strategy  Will this work for BSP 1.0 since one of its objectives is to stop man in the middle attacks?  What level does the testing take place at?  Highest level message syntax?  After parts of the message have been decrypted?  BSP sample applications and usage scenarios  Based on sample application for Basic Profile 1.0 adding security aspects

22 FUTURE WORK PLANS  Additional token profiles  Candidates include Kerberos, REL (XRML), SAML  Depends on progress by OASIS TC  Final material ETA: November, 2004

23 JOIN WS-I TODAY  Join  Join a community of more than 150 industry leaders and visionaries with a shared vision for Web services interoperability  Foster commitment across the community  Participate  Encourage customer participation and buy-in  Commit to an aggressive schedule for delivering resources to aid Web services implementations  Conform  Ensure implementations conform with WS-I profiles  Promote conformance to customers and partners

24 QUESTIONS  Today  Later   Comments on BSP documents   Security Scenarios published February, 2004  WGD.pdf WGD.pdf  BSP 1.0 WD published May, 2004  Thanks to Paul Cotton, chair of WS-I Basic Security Profile Working Group for much of the material in this presentation!