1 / 18

Language-Based Reasoning about WS-Security Protocols

Language-Based Reasoning about WS-Security Protocols. Andy Gordon Based on joint work with Karthik Bhargavan and C é dric Fournet. Microsoft Research. GALT'03, NeSC, Edinburgh, 16-17 October 2003. The Proposition. Two parallel trends over past five years:

brier
Download Presentation

Language-Based Reasoning about WS-Security Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Language-Based Reasoning aboutWS-Security Protocols Andy Gordon Based on joint work with Karthik Bhargavan and Cédric Fournet Microsoft Research GALT'03, NeSC, Edinburgh, 16-17 October 2003

  2. The Proposition • Two parallel trends over past five years: • Rapid invention and deployment of XML-based crypto protocols for securing web services • SOAP, XML-ENC, -DSIG, WS-Security, … • Sustained and successful effort to develop formalisms and tools to check crypto protocols • (Dolev&Yao, BAN,) FDR, Athena, Cryptyc, Proverif, … • New crypto protocols are often wrong, XML or not • Timely opportunity to develop tools for validating standards-based XML crypto protocols MSRC Samoa Project http://Securing.WS

  3. Scope of Dolev-Yao Model • The threat model is an attacker who can replay, redirect, assemble new messages, but cannot brute force secrets such as passwords • Can verify that crypto protocols establish various safety properties in spite of such an attacker: • Message authentication – against impersonated access • Message integrity – against parameter manipulation • Message confidentiality – against eavesdropping • Message freshness – against replays • Like all formal or informal methods, certain threats lie outside the model, and must be addressed separately • Disclosure of configuration data • Unauthorized access via SQL injection or cross-site scripting

  4. What’s a Web Service? • “A web service is a web site intended for use by computer programs instead of human beings.” (Barclay et al) • On public internets: Amazon, MSDN, … • Within intranet: vendor-neutral middleware to interconnect existing systems (IDC: North American companies implemented 3,300 WS projects in 2002) • Between intranets: inter-institution workflow (e-business, e-science); eg OGSI spec for “grid services”

  5. SOAP Request SOAP Response A Sample Web Service The Internet Smart client for checking orders www.bobspetshop.com [WebMethod] public Order GetOrder(int orderId) { return orderWebService.GetOrder(orderId); } PetShopService ws = new PetShopService(); Order o = ws.GetOrder(20); Implementation via proxy class and HTTP transport Implementation via WebService classes in Web Server Pet Shop database Vendor-neutral XML-encoding over HTTP WS-Security specifies how to sign or encrypt, etc

  6. Grids Over Web Services • “Grid” means different things to different people, eg: • WAN-based cpu-intensive e-science • LAN-based dynamically-provisioned server farms • Global Grid Forum: growing consensus to use SOAP • If not yet on how to handle mutable state • Need SOAP authentication to implement grid policies: • Who can read or write data? • Who pays for metered cpu time or disc space? • Who is licensed to run this software? • Who has priority on this freshly imaged server?

  7. Today’s Talk • Problem: • How to specify and verify authentication properties at the level of SOAP messages • Part I • Detailed Sample of Authentication via WS-Security • Part II • A Semantics of Web Services Authentication • XML data model with embedded crypto • Predicates for security tokens and signatures • Theorems about sample security protocols • Part III • Demo: verifier for XML security protocols

  8. Get Order Order Info Part I: Abstract vs XML Views of Simple Sample To see why we need to model XML in detail, we examine a typical authentication protocol as implemented for the Pet Shop sample site

  9. Sample Security Goals • Suppose a human A with password p uses a client I to invoke a web service at URL S • S = http://www.bobspetshop.com/ws/orderstatus.asmx • Without some kind of authentication, anybody could request the private details of anyone else’s order • Simple solution to require p-based signature of: • Message body • to show request from A, and has not been modified • Timestamp-based message identifier • to detect replays, with cache of recent messages • Web server S • to detect redirection from another server

  10. Routing header identifies action and server <Envelope> <Header> <path actor="next"> <action>http://bobspetshop/ws/OrderStatus</> <to>http://www.bobspetshop.com/ws/orderstatus.asmx</> <id>uuid:5ba86b04-3c0f-428b-8dd6-17804286fe40</> <Timestamp> <Created>2003-02-04T16:49:45Z</> <Expires>2003-02-04T16:50:45Z</> <Security> <UsernameToken> <Username>adg</> <Password>Ouywn2V6ikNNtWYL29gl9R3CPBk=</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI="#..."><DigestValue>Ego0...</> <Reference URI="#..."><DigestValue>5GHl...</> <Reference URI="#..."><DigestValue>efb0...</> <Reference URI="#..."><DigestValue>dFGb...</> <Reference URI="#..."><DigestValue>23io...</> <Reference URI="#..."><DigestValue>E4G0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo><SecurityTokenReference><Reference URI="#..."/> <Body> <GetOrder> <orderId>20</> A Signed Request UsernameToken assumes both parties know adg’s secret password p Password digest = sha1(nonce+time+p) proves knowledge of p Nonce to prevent replays; receiver needs to cache recently seen nonces Each DigestValue is the sha1 hash of the URI target URI arrows implemented using GUID Id attributes hmacsha1(key, SignedInfo) where key=psha1(p+nonce+time) Hence, signature can prove this is a fresh message from adg

  11. Part II: A Semantics of Web Services Security The XML wire format is trees plus pointers, rather more complex than the abstract trees of most Dolev-Yao models To reason at this level, we propose an XML model with symbolic crypto, that we embed within the applied pi calculus (paper at POPL’04) To the best of our knowledge, this is the first and only work on a formalism for XML-based crypto protocols

  12. XML Data 1: Standard Core • Sorts str, att, atts, itm, itms • Represents valid, parsed XML • Adapted from Siméon and Wadler's model (POPL’03) • Resembles the W3C Infoset recommendation Label ::= anyLegalXmlName element or attribute name String : str ::= any legal XML string XML string Att : att ::= Label="String" attribute Atts : atts ::= Att Atts |  attribute sequence Item : itm ::= Element | String item Items : itms ::= Item Items |  item sequence Element ::= <Label Atts>Items</Label> element

  13. XML Data 2: Crypto • Symbolic representation of crypto as in XML-DSIG • Omitting operations for XML-ENC, destructors, and the equational theory Bytes : bytes ::= byte array (not itself XML) s pi name, a nonce or key concat(Bytes1,Bytes2) array concatenation c14n(Item) canonical bytes of an item utf8(String) UTF8 rep of a string sha1(Bytes) cryptographic digest p-sha1(Stringpw,Bytessalt) key from salted password hmac-sha1(Byteskey,Bytessrc) keyed hash String : str ::= XML string s pi name, a password base64(Bytes) Base64-encoding of array principal(spw) from password to principal

  14. How Do We Apply The Model? • Use XML-based predicates to represent security checks made by SOAP processors • Express security goals as correspondences between each successful completion and its causal initiation • Embed the predicates and assertions within the pi calculus to represent behaviour of server and clients • Prove absence of attacks within pi threat model Our paper follows this recipe for a series of samples, but also discusses threats outside pi model

  15. A Concrete XML Protocol • Authenticity formalized as a correspondence; authorization decision not formalized • We describe this protocol as a process Q, and take the opponent O to be any arbitrary process in parallel • Theorem:Q|O is safe, that is, in every run, every end-event corresponds to a preceding begin-event • Proofs use a combination of process calculus techniques, and are compositional

  16. Part III: TulaFale Demo This summer, Riccardo Pucella has implemented an automatic verifier using Bruno Blanchet’s ProVerif

  17. Conclusions, Futures • Successfully bridged gap between theoretical pi threat model and XML used in WS security protocols • Driven by real samples, eg, MS Pet Shop • Faithful to XML message format • Found attacks within threat model • Proved theorems about wire-level protocols • Future directions • Analysis of more complex protocols • SOAP stack in an XML-aware type system • Grid-specific security problems? MSRC Samoa Project http://Securing.WS

  18. Securing.WS Resources • Projects: Samoa, Cryptyc, Proverif • http://Securing.WS • http://cryptyc.cs.depaul.edu • http://research.microsoft.com/~adg/cryptyc.htm • http://www.mpi-sb.mpg.de/~blanchet • Standards tracks and whitepaper • http://www.w3.org/2002/ws/ • http://www.oasis-open.org • http://msdn.microsoft.com/ws-security/ • My Top Three Web Service Blogs • http://www.gotdotnet.com/team/dbox/rss.aspx • http://weblogs.cs.cornell.edu/AllThingsDistributed/index.rdf • http://www.scottishlass.co.uk/rss.xml

More Related