Active Intermediaries in Web Service and E-Commerce Environments DIMACS Workshop on Security of Web Services and E-Comme

1. Active Intermediaries in Web Service and E-Commerce EnvironmentsDIMACS Workshop on Security of Web Services and E-Commerce, May 2005 John Linn RSA Laboratories, Bedford, MA, US

2. 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

3. Architectural Trend: The FITM • Increasingly, network and security architectures interpose active intermediaries ("Friends In The Middle", or, loosely, "FITMs") on paths • Examples in/around web services, e-commerce, elsewhere (e.g., pervasive, diverse, and controversial NATs) • FITMs have "interesting" properties • 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

4. 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 e-commerce FITM cases • Raise awareness of security-related trust assumptions, other issues introduced by FITMs • Suggest areas for future work

5. 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

6. 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

7. 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

8. 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

9. Communications Infrastructure Components • Type: Transparent or Transforming • Additional prospect: NAT as form of perimeter defense • 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 • Unless the methods impact data the components use • Transforming components are sometimes problematic (e.g., NATs and IPsec)

10. 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

11. 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

12. Spam Filters • Type: Filtering • Filters apply complex policies, including: • Sender identity and reputation • Message content elements, characteristics • Communication path attributes • Unpredictable filtering criteria disrupt communications availability • 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?

13. 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?

14. 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 time-sensitive data can be hard to ensure • IETF-OPES threat discussion in RFC-3837

15. Browser-Based Single Sign-On • Type: Passive Credential Holder • Servers place, obtain user credentials through holder • Simple example: Authentication cookies with HTTP browsers (RFC-2964 notwithstanding) • Assertion-based approaches • 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

16. 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

17. 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?

18. Conclusions • FITM usage is growing, often in order to achieve security goals • Protocols and practices gradually becoming FITM-aware, by design or default • FITMs are often unanticipated and controversial • Architects and evaluators must understand • 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