1 / 5

Are “proxies” trusted?

Are “proxies” trusted?. What are intermediaries authorized to do? For example, RFC3261 allows only the target domain of a request to retarget More famously, intermediaries can’t modify bodies, etc These fundamental authorization concepts are not explicit in RFC3261

mrachael
Download Presentation

Are “proxies” trusted?

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Are “proxies” trusted? • What are intermediaries authorized to do? • For example, RFC3261 allows only the target domain of a request to retarget • More famously, intermediaries can’t modify bodies, etc • These fundamental authorization concepts are not explicit in RFC3261 • “Everything that is not prevented by mechanism tends to be permitted in practice” • The reality is that SIP proxy servers behave as if UACs have no authority to exert any policy controls over the handling of their requests • The unenforcability of these restrictions creates security weaknesses for SIP • Because we allow for intermediaries, we also allow for attackers

  2. Retargeting creates insecurity • Service hijacking • Hotel proxy retargets all requests for Pizza Hut to Domino’s • Response identity • Unanticipated respondent • Establishment of security parameters • Choosing keys for crypto when retargeting is possible • Blacklist circumvention (“consent”) • If I don’t want to be called by someone, why on earth would I want to call them? • Transitivity • Proliferation of intermediaries obscure trust and force UAs to operate on hearsay

  3. Benefits of retargeting • Messaging efficiency • Less RTTs/messages sent • Target set privacy • Concealing location service mappings from UAs • Target set ordering enforcement • Sequential forking • Dialog control • Billing, third-party session termination of various kinds, etc • NAT Traversal for signaling • An absolute requirement

  4. Requirements • It MUST be possible for a UAC to detect when a request has been retargeted. • A domain that changes the target of a request MUST be capable of informing the UAC of the new target(s). • The mechanism MUST allow simple intradomain retargeting in cases where persistent TLS connections are used as a NAT traversal mechanism. • It must be possible for a domain that changes the target of a request to inform the UAC of the new target(s) prior to contacting any of the new target(s). There MUST furthermore be a way for intermediaries to determine when UACs require prior information about new targets. • It MUST be possible to preserve the privacy of targets and potential targets of requests. • It MUST be possible to preserve the ordering of a target set desired by the domain that changes the target of a request.

  5. What is the solution space? • Strategy 1: Provide a causal trace of intermediary agency after the fact • E.g., Request History (post-facto authorization at UAC) • Each intermediary sending a backwards-direction NOTIFY (i.e., an implicit SUBSCRIBE) • Strategy 2: Let the UAC explore new targets for a request rather than an intermediary • E.g., Redirection (before the fact authorization at UAC) • Spidering contacts via presence before sending a “real” request

More Related