Subject: [Sip] Media vs Signaling identity (was Re: francois' comments and why RFC4474 not used in the field)

From: Victor Pascual Ávila <[email-masked]>
Date: Tue, 31 Mar 2009 12:06:52 +0200

On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg <[email-masked]> wrote:
> inline:
>
> Jiri Kuthan wrote:
>
>
>>>  From an end user perspective, I would assert that the most important
>>> thing is probably the media. If the callerID says, "this is bob", what is
>>> important to the user, is that when I pick up the phone and start talking,
>>> it will be Bob who hears me, and Bob that I hear.
>>>
>>> Consider this litmus test:
>>>
>>> If the signaling actually came from Mary (perhaps as a third party), but
>>> the media goes/comes to/from Bob, who should appear on the caller ID? I say
>>> - Bob.
>>
>> There is a timing aspect in favor of placing identity in signaling --
>> I would like to know whose call is ringing before I answer (if I do).
>
> You can still have that. Just don't ring the phone until early media has
> been exchanged and verified. Indeed if you were doing an ICE-style thing per
> Dan's draft, you'd get that for free.

Are we restricting the identity assertion to telephony-like sessions?

IMHO, identity assertion should also work for the following scenarios
(among others):

-rfc3725, figure 1, message 1 (INVITE no SDP): Upon receipt of the
initial INVITE (note there's no session description at all), "A"
decides to authorize or reject the call based on the delivered
identifier.

-rfc3428, figure 1, message 2 (F2): "user2" decides to answer or
ignore the message based on the delivered identifier.

-rfc3515, example 4.1, message 1 (F1): "agent B" decides to accept or
reject the refer based on the delivered identifier

-Any other application based on white/black lists (where the identity
verification must happen before accepting a request).

While "signaling identity" seems to be a common denominator, I'm not
sure about the role of "media identity" in the above listed scenarios.
Any clarification will be appreciated.

Cheers,
-- 
Victor Pascual Ávila

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Mar 2009 13:31:50 -0400

inline:

> decides to authorize or reject the call based on the delivered

The identity is delivered via the signaling; you just need the media to 
verify it. This then enables a 'trust but verify model' - an attacker 
might get that initial call in but will be immediately detected and 
rejected when their media comes through.

> ignore the message based on the delivered identifier.

Its not obvious to me at this point, that we should be using exactly the 
same solution for MESSAGE as INVITE-based media sessions.

The general idea with 'media' is that the media stream itself - the true 
  user content - is what we are binding the identity to. User content is 
more difficult to modify because it is detectable by the user's 
themselves and disrupts the user's perception of the service. In the 
case of MESSAGE, it would be the content of the MESSAGE that we'd 
correlate the identity with. In that way, it doesn't matter what 
manipulations were made on any other aspect of the MESSAGE, but as long 
as the content is not manipulated - the identity matches.

For MSRP, something akin to DTLS-SRTP could be done, since its a media 
stream like RTP.

> reject the refer based on the delivered identifier

This one is tricky. Arguably the thing that represents the 'user 
content' and should be immutable is the Refer-To URI, but I have no 
doubt that b2bua muck with that header too.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com