Web Services Reliable Messaging and Security

1. Web Services Reliable Messaging and Security Paul Fremantle VP of Technology WSO2

2. About me • Co-founder and VP of Technology and Partnerships at WSO2 • The leading Open Source Web services company • Co-Chair of the OASIS WSRX Technical Committee • Committer on Apache Synapse • Member of the Apache Software Foundation • Co-author of Building Web Services in Java 2nd Edition • http://bloglines.com/blog/paulfremantle • Ex IBM Senior Technical Staff Member • developed the IBM Web Services Gateway • Apache WSIF • Apache Axis C/C++ • JWSDL/WSDL4J – now Apache Woden

3. Contents • Introduction to WS-Reliable Messaging • Composing WSRM and Security • Potential attacks on a reliable exchange • Securing the Sequence • Summary

4. WSRM Aims • To help ensure that messages are delivered to their destination • Exactly Once In Order is the most common requirement • “Composable” with other specifications and existing systems • Doesn’t re-implement those aspects • Has the ability to work with other standards (security, transactions, addressing)

5. History • A specification designed by IBM, Microsoft, BEA and Tibco • Designed to compose with WS-Addressing, WS-Policy • Originally published in March 2003 • Refreshed March 2004, Feb 2005 • Submitted to OASIS June 2005

6. This presentation • Mainly based on the public review (CD4) of WSRM 1.1 (OASIS) • With appropriate comments on the Submission spec (WSRM 1.0)

7. WS-Reliability • An alternative specification proposed by Fujitsu, Hitachi, NEC, Oracle, Sun • Submitted to OASIS and standardized, currently at v1.1 • One available implementation: • RM4GS Reliable Messaging for Grid Service • A sample/reference implementation

8. Confusion OASIS WSRM committee WS-R WSRM WS-RX committee

9. Actional Corporation Adobe Systems BEA Systems, Inc. BTplc Choreology Ltd. Ericsson Fujitsu Limited Hitachi, Ltd. IBM IONA Technologies JBoss Inc. Microsoft Corporation NEC Corporation Nortel Networks Limited Novell Oracle Corporation SAP AG Sonic Software Corp. Sonoa Systems, Inc. Sun Microsystems Tibco Software Inc. webMethods, Inc. WSO2 WS-RX TC members includerepresentatives of: While the TC is working from the submitted spec, it aims to meet the requirements of all the TC members within the scope of the charter

10. Introduction to WSRM

11. The core model • CreateSequence and CreateSequenceResponse • Messages allocated to the sequence • Acknowledgement • Resend of unacknowledged messages • TerminateSequence and TerminateSequenceResponse

12. Simple example

13. WS-RM core model

14. Delivery Assurances • Previous spec (1.0) explicitly called out the delivery assurances: • At least once • At most once • Exactly once (at least+at most) • InOrder • 1.1 allows the RMD to specify • IncompleteSequenceBehaviour • DiscardEntireSequence • DiscardFollowingFirstGap • NoDiscard

15. Verbs • SOAP Body: • CreateSequence/CreateSequenceResponse • CloseSequence*/CloseSequenceResponse* • TerminateSequence/TerminateSequenceResponse* • SOAP Header: • Sequence • AckRequested • SequenceAcknowledgement * Indicates added since submitted to OASIS

16. CreateSequence <wsrm:CreateSequence ...> <wsrm:AcksTo ...>wsa:EndpointReferenceType</wsrm:AcksTo> <wsrm:Expires ...> xs:duration </wsrm:Expires> ? <wsrm:Offer ...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> <wsrm:Expires ...> xs:duration </wsrm:Expires> ? ... </wsrm:Offer> ? ... </wsrm:CreateSequence>

17. CreateSequenceResponse <wsrm:CreateSequenceResponse ...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> <wsrm:Expires> xs:duration </wsrm:Expires> ? <wsrm:AcknowledgementInterval Milliseconds="xs:unsignedLong" />? <wsrm:Accept ...> <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo> </wsrm:Accept> ? ... </wsrm:CreateSequenceResponse>

18. CreateSequence/Response • Sent in the body • AcksTo specifies the place where acknowledgements are sent • Expires is optional • Offer is an optional way of initiating a Sequence in the reverse direction • Can respond with CreateSequenceRefused fault

19. CloseSequence • Sent from the RMS to the RMD • Added to help close down incomplete sequences • After a sequence is closed, no new messages are received • But still responds to AckRequested • Allowing the final state of the sequence to be ascertained <wsrm:CloseSequence ...> <wsrm:Identifier ...>xs:anyURI</wsrm:Identifier> ... </wsrm:CloseSequence>

20. TerminateSequence • Sent from the RMS to the RMD - indicates that the sequence will no longer be used • Normally sent when the sequence is complete – all sent messages have been acknowledged • Can be sent at any time <wsrm:TerminateSequence ...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> ... </wsrm:TerminateSequence>

21. TerminateSequenceResponse <wsrm:TerminateSequenceResponse ...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> ... </wsrm:TerminateSequenceResponse> • This was added by the TC to allow the RMS to know that the RMD successfully terminated the sequence

22. Sequence Header <wsrm:Sequence ...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> <wsrm:MessageNumber> wsrm:MessageNumberType </wsrm:MessageNumber> ... </wsrm:Sequence> • The primary header – added to every message that is in a Sequence • Adds the sequence identifier and the message number

23. AckRequested <wsrm:AckRequested ...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> ... </wsrm:AckRequested> • Allows a RMS to request an acknowledgement from the RMD • RMD must reply at once • Must be a full acknowledgement (no Partial Answer Mode)

24. SequenceAcknowledgement <wsrm:SequenceAcknowledgement ...> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> [ [ [ <wsrm:AcknowledgementRange ... Upper="wsrm:MessageNumberType" Lower="wsrm:MessageNumberType"/> + | <wsrm:None/> ] <wsrm:Final/> ? ] | <wsrm:Nack> wsrm:MessageNumberType </wsrm:Nack> + ] ... </wsrm:SequenceAcknowledgement> • A complete set of ranges • May be Final – indicating no more messages will be accepted • Or None (may be Final) • Or Nacks of individual messages

25. “Optimistic” model • Because the whole Sequence is acknowledged, it is possible to use WSRM with very little overhead over a sequence of messages • CreateSequence • Messages flow with Sequence headers, plus occasional acknowledgements • TerminateSequence

26. Offer and Accept • Offered sequence is a way of cutting down the “back-and-forth” • There is no specific requirement that the Offered sequence is used for responses • But usual behaviour

27. WSRM Policy <wsrmp:RMAssertion wsp:Optional=true/> The submitted spec had a number of parameters available in policy. AcknowledgementInterval was moved to CS Dynamic optimization of protocol timing is more effective than static parameters.

28. A two-way reliable interaction Client Server CreateSequence + Offer CreateSequenceResponse(A) + Accept(B) Request 1 Response 1 + ackA1 Request 2 + ackB1 Request 3 + AckB1 Response 3 + ackA123 Response 2 ackB123 TerminateSequence(A) TerminateSequenceResponse + AckA123_Final TerminateSequence(B) TerminateSequenceResponse + AckB123_Final

29. Anonymous clients • The protocol supports one-way reliability with anonymous clients • May be reliable-in/unreliable-out • acksTo will be anonymous • Uses piggybacked acks

30. Anonymous clients and two-way • The WSRM1.1 specification has added a new verb to support this: MakeConnection client CS+Offer(seq2) server CSR(seq1)+Accept msg1(seq1) response1(seq2) +ack(seq1) msg2(seq1) + ack(seq2) msg3(seq1) + ack(seq2) response3(seq2) + ack(seq1) MakeConnection(seq2) response2(seq2)

31. Uptake • Still gated by lack of a “standard” • Industry has definitely moved to WSRM spec • Examples: • Canadian government project built a solution on WSRM spec • A major Wall Street bank is looking at widespread adoption of WSRM • Ford and Daimler Chrysler are planning major implementations • Other groups such as RAMP, FIXprotocol, will profile RM

32. Composability with Security • WSRM is inherently designed to compose with security systems • SSL/TLS • WS-Security • WS-SecureConversation

33. Basic Composability WS-Security WS-ReliableMessaging WS-AtomicTransactions Secure Transactional Secure Reliable Transactional Secure Reliable Reliable Transactional

34. Composability works! • Numerous demonstrations of WSRM + WSSecurity • WSRM and WSSecureConversation • WSO2’s Web Service App Server fully supports these combinations 

35. Composability isn’t enough • Unfortunately, there is a problem • Composability ensures that the application can be secured • But doesn’t secure the sequence

36. Why isn’t SSL or WSSec enough? RM enabled system Party 1 Authorized RM Sequence Attack on Sequence Party 2 Authorized

37. Sequence attacks are real • Probably the most famous hack ever was a sequence attack • TCP Sequence Prediction • Based on predicting the correct sequence number for a packet and getting your packets in first • First identified by Robert Morris in 1985 but thought impractical and unlikely • Actually implemented by Kevin Mitnick against Tsutomu Shimomura on Christmas Day 1994

38. So what can we learn from this? 1. Don’t login on Christmas Day 2. Protect your sequence

39. Integrity • Threats • Any modification to any of the RM protocol messages • Countermeasures • Signing the headers • To prevent headers being swapped, Sequence headers should be signed with the body

40. Denial of Service • Threat • Many unused CreateSequences • Target an in-order sequence with missing messages • Countermeasures • Restrict sequence creation to authorized parties • Monitor sequences for DoS attacks • Similar to secure TCP stacks

41. Sequence Spoofing • Threats • Hijacking • Injecting fake or wrong messages into a sequence • Incorrectly acknowledging messages • Countermeasures • Tie the Sequence to a security context • Each side associates the sequence with security credentials used during creation • Only accepts Sequence Traffic from the same entity

42. SSL/TLS example Create SSL/TLS session(s) RMS RMD Send CreateSequence over TLS session CreateSequenceResponse over TLS Sequence Traffic / TLS  Sequence Traffic / different TLS  Sequence Ack / TLS   Sequence Ack / different TLS

43. Ensuring that the Sequence is secure • Add this header block <wsrm:UsesSequenceSSL soap:mustUnderstand=“true” ... /> • The mustUnderstand ensures that the RMD “agrees” to the contract • Otherwise it should fault

44. Restrictions • SSL / TLS is only point-to-point • Any intermediaries must be trusted to maintain integrity • The sequence must last no longer than the SSL/TLS session

45. WS-Security • Provides SOAP message security • Authentication • Encryption • Message and header digital signatures • Message level security

46. SecureConversation • An extension to WS-Security that allows a secure context to be established between two parties • Potentially used together with WS-Trust

47. Secure Conversation

48. Benefits over just WS-Security • In WS-Security, a public key is used for every message • Highly inefficient

49. WS-SecureConversation in RM <wsrm:CreateSequence> … <wsse:SecurityTokenReference> ... </wsse:SecurityTokenReference> </wsrm:CreateSequence>

50. SecureConversation example Create WSSC secure context RMS RMD Send CreateSequence including STReference CreateSequenceResponse Sequence Traffic, signed headers and body  Sequence Traffic / different SecurityContext  Sequence Ack including STReference   Sequence Ack / different context