Promoting Web services interoperability across platforms,applications and programming languages

Paul Cotton, MicrosoftJune, 2004

2

Outline

Introduction WS-I goals WS-I organization and deliverables Web services security standards OASIS WS-Security TC WS-I Basic Security Profile Working Group WS-I Security Scenarios WS-I Basic Security Profile 1.0 Questions

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

THE CHALLENGE

“[the] architecture of Web services is not fully crystallized. Without guidance, standards may fragment”

Gartner “Inevitably, companies involved with Web services will

define them in their own way. The term Web services will be a messy catchall phrase.”

Intelligent Enterprise

“standards…allow Web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so multiple applications can interact.”

eWeek

5

THE OPPORTUNITY

HTTP, HTML

XML

Web Services

Ma

rke

t Imp

act

1995 1997 1999 2001 2003 2005WS

-I form

ed

6

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

7

GOALS

Achieve Web services interoperability

Across platforms, applications and languages Encourage Web services adoption

Among customers, industries and end users Accelerate Web services deployment

8

ACHIEVE INTEROPERABILITY

Promote a common, clear definition for Web services Integrate specifications from various standards bodies Provide a visible representation of conformance through

use of WS-I logo

9

ENCOURAGE ADOPTION

Build industry consensus to reduce early adopter risks Provide a forum for end users to communicate

requirements Act as a customer advocate to raise awareness of

business requirements

10

ACCELERATE DEPLOYMENT

Offer implementation guidance and best practices Deliver tools and sample applications Provide a forum for Web services developers to

collaborate and share expertise

11

ORGANIZATION

Board of directors

Management and administration body

Ensure the organization and its working groups adhere to their defined scope

Working groups

Develop materials and other deliverables to aid Web services interoperability

Membership

Vote to approve adoption and distribution of any materials developed by the working groups

12

TECHNICAL WORKING GROUPS

Basic Profile

Chris Ferris, IBM Scenarios and Sample Applications

Marc Goodner, SAP Testing Tools and Materials

Narendra Patil, Optimyz Software Basic Security Profile

Paul Cotton, Microsoft Requirements Gathering

Rimas Rekasius, IBM

13

WORKING GROUP DELIVERABLES

Profiles

Named groups of specifications at given version levels with conventions about how they work together

Use cases and usage scenarios

Solution scenarios based on customer requirements Sample code and applications Test suites and supporting materials

Conformance testing tools

Supporting documentation and white papers

14

SAMPLE DELIVERABLES

usage scenarios sampleapplications

scenarios and

sample

applications

use cases

web services

basic profile

testingtools

other test materials

testing tools

and materials

profiles

15

PROFILES

Provide guidance on general purpose Web services functionality

Address interoperability at a level above specification-by-specification

Supporting specifications and standards will be considered from multiple industry sources

Profile development will reflect market needs and requirements

19

USE OF DELIVERABLES

The public is free (and encouraged) to

Download, use, and review each Profile

Download and use test tools and material to test their applications

Download, use, modify, and redistribute WS-I sample applications Adopters may (in addition to the above)

Reproduce and redistribute specifications with their products Members may (in addition to all of the above)

Ship test tools and material (as is or modified) within their products

22

KEY MILESTONES

Delivered Basic Profile 1.0 (Aug, 2003) Profile of SOAP 1.1, WSDL 1.1, UDDI 2.0

Delivered Sample Applications 1.0 (Dec, 2003) Delivered Basic Profile 1.1, Attachments Profile 1.0 and Simple SOAP

Binding Profile 1.0 Working Group Drafts (Dec, 2003) Reorganization of Basic Profile 1.0

Profile of SOAP with Attachments Delivered Security Scenarios Working Group Draft (Feb, 2004) Delivered Testing Tools 1.0 (Mar, 2004) Delivered Basic Security Profile Working Draft (May, 2004) Future

Final materials on BP 1.1, AP 1.0, SSBP 1.0

Final materials on BSP 1.0

More Testing and Sample Apps materials

23

WS-I AND STANDARDS BODIES

Web services standards come from a variety of bodies

W3C, OASIS, IETF, ISO, ECMA, etc. WS-I is a standards integrator

Downstream from standards organizations

Upstream from industry and industry consortia

Ensure interoperability of implementations Collaboration with other bodies is a requirement

24

WS-I, STANDARDS AND INDUSTRY

Businesses, Industry Consortia, Developers, End-Users

Requirements

Standards andSpecifications

Requirements

ImplementationGuidance

25

WS-I AND STANDARDS BODIES

Support relationships with standards bodies who own specifications referenced by WS-I profiles

Ensure consistency

Minimize redundancy Foster communication and cooperation with industry

consortia and other organizations

27

WEB SERVICES SECURITY STANDARDS

WS-FederationWS-

SecureConversation WS-Authorization

WS-Policy WS-Trust WS-Privacy

XKMS

XMLEncryption

XMLDigital

Signature

SOAP Foundation

WS-SecuritySAML XACML SPML

28

OASIS WS SECURITY TC

OASIS Web Services Security TC created September, 2002 Interoperability testing Summer 2003 Voted Committee Draft September, 2003

Core specification plus Username and X.509 tokens Public Review completed October, 2003 Adopted as OASIS standard in January, 2004 REL (XRML) token type voted CD June, 2004 Other token types under interoperability testing

Kerberos, SAML, etc.

29

OASIS WSS

Security Header Can contain mustUnderstand Can be addressed to Role

Tokens Associated with signature or encryption or otherwise used to identify party

to message exchange Binary Token - encapsulates binary object

X.509 certificate – defined by ITU/IETF Kerberos ticket – defined by IETF/Microsoft

XML Token – inserted as is Username Token – defined by OASIS WSS TC SAML Assertion – defined by OASIS SS TC REL (XrML License) – defined by ContentGuard

30

OASIS WSS

Security Token Reference Points to or encapsulates a token

Four types Direct – URI or URI fragment

Key Identifier – specific to token type – identifies key, certificate, ticket, assertion, etc.

Key Name – identifies token by content, e.g. SubjectName

Embedded – encapsulates token, allows association of additional information with token

Signature element New transform - STR Dereference Transform

Encryption ReferenceList or EncryptedKey elements Timestamp element

Only applies to security mechanisms

Created and/or Expires

31

WS-I BASIC SECURITY PROFILE WG

BSP WG chartered in March, 2003 Two initial deliverables

Security Scenarios

Basic Security Profile 1.0 Based of Basic Profile 1.0 and the following technologies:

– HTTP over TLS

– SOAP with Attachments

– WSS and X.509, username & Kerberos tokens

Complete by 9 months after WSS is Committee Draft (Sep, 2003)

Large WG with over 20 active member companies

32

SECURITY SCENARIOS WORKING DRAFT

Security Challenges Threats Security Solutions and Mechanisms

Transport Layer & Message (SOAP) Layer Scenarios

Generic Requirements (no scenario-specific ones yet)

Scenarios (From WS-I Sample Applications) One-way

Synchronous Request/Response

Basic Callback

Others?

Feb 2004 draft for public comment http://ws-i.org/Profiles/BasicSecurity/2004-02/SecurityScenarios-0.15-WGD.pdf

33

SECURITY SCENARIO SECTIONS

ThreatsChallenges

MechanismsScenarios

34

THREATS – IN SCOPE

In scope 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

35

THREATS – OUT OF SCOPE

Out of Scope Key Attack / Weak Algorithm Traffic Analysis Host Penetration / Access Network Penetration / Access Timing Covert Channels Message Archives Network Spoofing Trojan Horse Virus Tunneling Denial of Service - Other

36

SECURITY SOLUTIONS AND MECHANISMS

Integrity, Confidentiality, Authentication, Attributes Transport Layer (HTTP/HTTPS)

HTTP & SSL/TLS mechanisms Message Layer

WSS mechanisms Combinations

Large number of theoretically possible combinations

Identified nine believed to be of practical utility Security Considerations

Properties, Threats addressed, Limitations

37

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

38

SCENARIOS

Notations and conventions Generic requirements

Peer Authentication

Integrity

Confidentiality

Origin Authentication Scenario descriptions

One-Way

Synchronous Request / Response

Basic Callback

Others?

39

SECURITY SCENARIOS - CURRENT WORK

How to secure SOAP with Attachments used by Attachment Profile 1.0?

WG Charter originally proposed S/MIME WG has decided that it is better to extend Web Services

Security to handle AP 1.0 OASIS WSS TC now working on a proposed solution Final Security Scenarios expected in Aug, 2004

40

WS-I BASIC SECURITY PROFILE (BSP) 1.0

Guiding principles of profile design No guarantee of interoperability Focus profiling effort Application semantics Testability Strength of requirements Restriction vs. relaxation Multiple mechanisms Future compatibility Compatibility with deployed services Focus on interoperability Conformance targets Do no harm

41

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. optionality in spec)

Many have since been dropped First public WD published May, 2004

http://ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html

42

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

43

EXAMPLE REQUIREMENT

4. Transport Layer SecurityThis section of the Profile incorporates the following specifications by reference, and defines extensibility points within them: HTTP over TLS

Extensibility points: E0001 - Ciphersuites - Additional ciphersuites may be specified.

4.1 SSL and TLSThe following specifications (or sections thereof) are referred to in this section of the Profile;

HTTP over TLS: Section 2.2.1 SSL and TLS are both used as underlying protocols for HTTP/S. This profile places the following constraints on those protocols:

4.1.1 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

44

OTHER BSP 1.0 DELIVERABLES

usage scenarios sampleapplications

scenarios and

sample

applications

use cases

web services

basic security profile

testingtools

other test materials

testing tools

and materials

profile

45

TESTING AND DEMONSTRATING BSP 1.0

How to test Basic Security Profile 1.0?

BP 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 BP 1.0 adding security aspects

46

FUTURE WORK PLANS

Security ScenariosAdd text for attachments using WSS

Final material ETA: Aug, 2004 Basic Security Profile 1.0

Small number of issues pending work by OASIS TC

Add text for attachments using WSS pending work by OASIS TC

Final material ETA: Sep, 2004 Additional token profiles

Candidates include Kerberos, REL, SAML

Depends on progress by OASIS TC

Final material ETA: Nov, 2004

47

QUESTIONS

Today Later

mailto:pcotton@microsoft.com Comments on BSP documents

mailto:wsi_secprofile_comment@lists.ws-i.org Security Scenarios published Feb, 2004

http://ws-i.org/Profiles/BasicSecurity/2004-02/SecurityScenarios-0.15-WGD.pdf

BSP 1.0 WD published May, 2004

http://ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html