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 redirected to
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