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 isnt 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 wouldnt 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 arent 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 dont 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_at_neustar.com
  redirected to jon.peterson_at_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 isnt 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 shouldnt 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