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

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

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”

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’

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

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

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

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

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

Authorization Decisions at UACs