Active Intermediaries in Web Service and E-Commerce Environments DIMACS Workshop on Security of Web Services and ECommerce, May 2005 John Linn RSA Laboratories, Bedford, MA, US Traditional End-to-End Model End-to-end principle (Saltzer, Clark, Carpenter (RFC-1958), others) has been central in Internet communications and security architecture Goal: place functions near applications that need them, minimize dependence on intermediaries From a security perspective, the "network cloud" is a perilous, stormy sea Ship messages in strong containers, don't open until delivery at destination Architectural Trend: The FITM Increasingly, network and security architectures interpose active intermediaries ("Friends In The Middle", or, loosely, "FITMs") on paths FITMs have "interesting" properties Examples in/around web services, e-commerce, elsewhere (e.g., pervasive, diverse, and controversial NATs) Often designed and managed independently from endpoint applications Can be peers, relays, filters, or encapsulators for protocols they process Can be wholly, partially, or not at all trusted for particular aspects of security Traditional security methods see FITMs (like other MITMs) as potential intruders, to be worked around Goals of This Talk Establish taxonomy and context for FITM types and operational roles Seek general framework to structure FITM discussion Consider example web service and ecommerce FITM cases Raise awareness of security-related trust assumptions, other issues introduced by FITMs Suggest areas for future work A Taxonomy for FITM Types Transparent Caching Filtering Transforming Passive Credential Holder Cryptographic Peer Access Point Note: Concrete components can combine processing of multiple types FITM Roles NN: No impact on service, or on subscriber methods to achieve it NI: No impact, but may impact subscriber methods PN: Passive involvement in service (processes securely), not impacting subscriber methods PI: Passive involvement, may impact subscriber methods AN: Actively providing service (explicitly implements security functions), not impacting subscriber methods AI: Actively providing, may impact subscriber methods Note: Roles are relative to specific combinations of protocols and security services Observation: Many "non-security" components are relied upon to provide important security properties FITMs and Security Services Most FITMs are PN or PI for "traditional" security services (authentication, integrity, confidentiality, non-repudiation) Exceptions: Cryptographic Peer, Access Point Most FITMs are PN for availability Most FITMs are NN for perimeter defense Exceptions: Filtering, Transforming, Access Point Some FITM Examples Communications infrastructure components Firewalls Multi-tier servers Spam filters Web proxies Content distribution networks Browser-based single sign-on Multi-hop SOAP processing Communications Infrastructure Components Type: Transparent or Transforming Users implicitly trust communications components for many security properties Correct routing to intended destinations (i.e., confidentiality) Integrity, authenticity, and availability of traffic Transparent components are usually compatible with end-to-end security methods Additional prospect: NAT as form of perimeter defense Unless the methods impact data the components use Transforming components are sometimes problematic (e.g., NATs and IPsec) Firewalls Type: Filtering Firewalls provide perimeter defense by filtering traffic Implicitly trusted for integrity, confidentiality, and availability purposes End-to-end SSL/TLS conflicts with effective filtering on higher-layer data Common TCP/UDP port filtering motivates squeezing data through the HTTP "loophole" Processing rules becoming more complex Firewalls become intermediary application entities, add Transforming operations Non-transparent behavior can be hard to diagnose Multi-tier Servers Type: Transforming Many deployments expose one web server facing the Internet, transform requests for separate processing in "back end" tiers Motivations include perimeter defense Issue: Granularity and propagation of authenticated identities Span of SSL/TLS authentication terminates at Internet-facing entity Message-level protection or out-of-band means may be needed for back end to validate original requester Spam Filters Type: Filtering Filters apply complex policies, including: Unpredictable filtering criteria disrupt communications availability Sender identity and reputation Message content elements, characteristics Communication path attributes Silent dropping of false positives violates implicit trust Policies evolving rapidly, endpoints often unable to identify or control enforcement points A harbinger of likely chaotic results when pervasive intermediary-based services are subject to abuse? Web Proxies Type: Transforming and/or Caching Proxies accept requests from browsers, translate into new requests to target sites Implicitly trusted for authentication, integrity, confidentiality purposes Application-layer processing can impose new trust requirements on ISPs, other communications intermediaries Depending on method, proxied data may be authenticated to source or to proxy Privacy dilemma: proxy as anonymizing privacy protector or as well-placed snoop? Content Distribution Networks Type: Transforming and/or Caching CDNs allow the contents of a "site" to be dispersed towards their consumers Generally, data authenticated to intermediary, not original source Could sign and verify some types of content objects, but not standard practice and infeasible for, e.g., translation Freshness and consistency guarantees on timesensitive data can be hard to ensure IETF-OPES threat discussion in RFC-3837 Browser-Based Single Sign-On Type: Passive Credential Holder Simple example: Authentication cookies with HTTP browsers (RFC-2964 notwithstanding) Assertion-based approaches Servers place, obtain user credentials through holder Examples: Liberty ID-FF, SAML, WS-Federation Passive Requestor Authentication server generates assertion on behalf of user, browser relays to relying party Operational scenarios often complex, with multiple protocols providing different assurances Issue: constraining use of assertions and artifacts Gross (CSAC, 2003) SAML 1.0 analysis, OASIS SSTC working on response Multi-Hop SOAP Processing Type: Transforming and/or Cryptographic Peer SOAP (and WSS:SMS) operational model allows intermediaries to modify message headers before ultimateReceiver Example usage: firewall could verify signature, re-sign in different form (Bhargavan, et al., 2004) SOAP is unusual in explicitly embracing FITMs in model, even though two-peer operation is most common current case Q: Where and how will this generality prove most useful? Need consistency on methods' span, granularity, and semantics Must pair encryption and decryption points and scopes properly Can sign header elements for use at multiple verifiers, but checks fail unless a verifier can obtain the elements that produced them E.g., verifier that can't decrypt a data object also can't verify a signature on its plaintext form Trust implications of translated signatures Distilling FITM-Related Issues What entities (endpoints and FITMs) perform or influence a protocol's operations, and in what roles? What properties must a FITM be trusted to provide or maintain? Who is a FITM acting for? How do endpoint and FITM policies and methods interact? Are the endpoint subscribers: Unaware of FITMs? Reliant on FITM functions without directly communicating with them? Explicitly cognizant of FITMs, requesting their services? Conclusions FITM usage is growing, often in order to achieve security goals Architects and evaluators must understand Protocols and practices gradually becoming FITMaware, by design or default FITMs are often unanticipated and controversial What assurances FITMs can offer, and to whom What properties to achieve end-to-end How the above compose or collide Further research on FITM-bearing security models will be important