Re: Media vs Signaling identity (was Re: francois' comments and why RFC4474 not used in the field)
Jonathan Rosenberg <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
inline: Victor Pascual Ávila wrote: > On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg <[email protected]> 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. 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. > > -rfc3428, figure 1, message 2 (F2): "user2" decides to answer or > 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. > > -rfc3515, example 4.1, message 1 (F1): "agent B" decides to accept or > 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 protected] http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip