Active Intermediaries in Web Service and ECommerce Environments DIMACS Workshop on Security of Web S

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 WSSSMS) 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