slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Active Intermediaries in Web Service and E-Commerce Environments DIMACS Workshop on Security of Web Services and E-Comme PowerPoint Presentation
Download Presentation
Active Intermediaries in Web Service and E-Commerce Environments DIMACS Workshop on Security of Web Services and E-Comme

Loading in 2 Seconds...

play fullscreen
1 / 18

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


  • 188 Views
  • Uploaded on

Active Intermediaries in Web Service and E-Commerce Environments DIMACS Workshop on Security of Web Services and E-Commerce, May 2005. John Linn RSA Laboratories, Bedford, MA, US. Traditional End-to-End Model.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Active Intermediaries in Web Service and E-Commerce Environments DIMACS Workshop on Security of Web Services and E-Comme' - bernad


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

traditional end to end model
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
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
goals of this talk
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
a taxonomy for fitm types
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
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
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
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
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)
firewalls
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
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
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?
web proxies
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
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
browser based single sign on
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
multi hop soap processing
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
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
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