Active Intermediaries in Web Service and E-Commerce Environments

advertisement
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
Download