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
