sip-identity-04

1. sip-identity-04 • Added new response codes for various conditions • Softened ‘direct TLS connection’ requirement • Added support for CID URI in Identity-Info • Added some non-normative text about requests in the backwards direction within a dialog

2. New Open Issues • Fixing 6.1 • Display-name handling • Should the identity signature cover the display-name? • Transitional authorization policy • How do you know if a domain supports sip-identity? • Privacy interaction • RFC3323 isn’t so current anymore • URI scheme for Identity-Info • Should SIPS be an option? • Or should it just be a fetch (like, HTTP) • Applicability to REGISTER • tel URI handling • domain certs v. end-user certs • Name subordination rules

3. What is Response Identity? • A mechanism that allows UACs to detect that responses come from an impersonator • Flip side of request identity • sip-identity-04 wouldn’t work if it were applied as-is to responses (assuming flipping From for To) • The problem: signature over the To header field in a response would come from the actual ‘connected’ domain • -Not- the original target domain of the request, when retargeting has taken place • Thus, the root cause of response identity problems is retargeting • That is, if there were no retargeting, response identity would “just work”

4. Response Identity is Hard™ • Issues: • Who are you impersonating when you forge a response? • What are intermediaries authorized to do when routing SIP requests? • How would a UAC make authorization decisions on the basis of response identity? • Architectural properties that make this harder: • Lack of distinction between AoRs and contract addresses and ‘identities’

5. Impersonate who? • Biggest difference between request and response identity is: • In a transaction, a request can only come from one identity… • But a response can legitimately come from tens or hundreds or thousands of entities • Who is authorized to respond to a request? • The set of corresponding addresses in the location service of the target domain • But, that is just a logical concept – a domain can populate location services arbitrarily • So who might an impersonator impersonate? • The original target URI is one possibility • As are any translated contacts (possibly a very large set) if known by the adversary • But, an impersonator can just “be themselves” – how would a UAC know that they aren’t authorized? • This is our first hint that the problem is architectural

6. Identities, AoRs, and contacts • When I respond legitimately, who am I, really? • I may be capable of registering under many AoRs • I don’t just have one unique identity – which one should I use? • The identity to which a request was originally sent may be a valid AoR for the respondent • E.g., a request to jon.peterson@neustar.com redirected to jon.peterson@neustar.biz • Does retargeting change the identity from which you respond? • Should it? • What about non-AoR targets (contact addresses)? • The ultimate target of a request isn’t likely to be an AoR • No way to tell from inspecting a URI if it represents a user, device, or what have you • Sipping-sip-arch 4.3

7. Difficulty of Response Impersonation • Huge difference in threat model between request and response identity • Request identity: adversary can forge a From header field • Requires adversary to control their own device • Response identity: • Adversary can eavesdrop on traffic to capture transaction/dialog identifiers • Adversary can suppress or somehow complement legitimate responses • Adversary can reinsert forged responses into any existing persistent transport-layer connections • Actually impersonating a legitimate respondant requires a great deal of sophistication

8. What is the solution space? • Strategy 1: Increase transaction security • Try to prevent adversaries from learning enough about transactions/dialogs to forge responses • Strategy 2: 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 3: 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 • Strategy 4: Essentially do nothing – bar for attackers is high enough that we shouldn’t worry

9. Permissions of Intermediaries • The architectural problem: • A UAC wants to authorize a specific intermediary to change the target of a request • That intermediary, in turn, wants to authorize a specific set of respondants to provide responses • Any response outside of that set is NOT authorized

10. Authorization Decisions at UACs