Re: [rtcweb] Use case change request: Identity in multiuser calls

[Igor Faynberg <[e-mail]>]

Well...

(I thought that the lawful intercept issue that came up several times is 
pertinent here.)  But note that this was a parenthetical remark!

A non-parenthetical one is based on the quote from the cited draft:

"In the development of ZRTP, it was realized that there are scenarios
    in which the media can not be encrypted end-to-end.  For example,
    when a client has a trusted server or PBX which provides media
    services in the path.  For these cases, ZRTP developed mechanisms for
    handling a "trusted MiTM" which can terminate than reoriginate the
    SRTP encryption."



So, if we end up with a "trusted MITM," why not have a trusted central 
server in the first place?

Igor

P.S.:  I have nothing against ZRTP, which has done a thorough and honest 
job.  I question its applicability to the agreed use cases. Personally I 
think we need an all-encompassing solution.


On 8/11/2011 3:11 PM, Henry Sinnreich wrote:
>> Henry - what sort of mechanism did you have in mind for these anonymous
>> participants to identify themselves to one another? Are you talking
>> about the exchange of credentials using the server as an intermediary in
>> the exchange? Or did you have in mind an exchange outside the server.
>> (E.g. Bob establishes a secure connection to Alice and over it tells her
>> "I'm anon2 in conference foo right now"?
> The most credible e2e identification that comes to my mind is Phil
> Zimmermann's Zfone technology:
>
> http://www.ietf.org/id/draft-johnston-rtcweb-media-privacy-00.txt
> http://zfoneproject.com/
>
> Definitely not relying on any "trusted" server :-)
>
> Thanks, Henry
>
> On 8/11/11 11:50 AM, "Paul Kyzivat"<[e-mail]>  wrote:
>
>> On 8/11/11 12:07 PM, Henry Sinnreich wrote:
>>>> The participants are identified to
>>>> each other by the central server
>>> There may be no contradiction, but just to make sure the scenario, such as a
>>> confidential business meeting is included (not necessarily a social network
>>> scenario).
>>>
>>> A confidential conference MUST assure that all participants can also be
>>> safely identified first to each other, not necessarily by the server, end to
>>> end, to the full satisfaction of all the participants, who would otherwise
>>> refuse to continue  to speak up or continue to attend at all.
>>> Who provides for the e2e identification? A 3rd party? Inside the app?
>>>
>>> Did I understand correctly there is no contradiction?
>>> Any problem in clarifying this?
>> This is an example of the sort of thing I was speaking of in my earlier
>> reply - that there are differing levels of identity that may be desired.
>>
>> In some cases, participants may want to be fully anonymous. But even
>> then, it will typically be important that one participant be able to
>> identify *which* of the other (anonymous) participants it is receiving
>> media from. (E.g. by noting which participant in the roster is the
>> current speaker - anon1, anon2, ...)
>>
>> In other cases the participants *true* identities are hidden, but
>> handles/nicknames may be used to identify them in the roster and in
>> chats. ("snoopy" and "red barron" rather than anon1 and anon2.)
>>
>> But in that case there are issues of how the handles are associated with
>> participants. It could be that handles are permanently assigned to real
>> users by the server. Then you can be confident that when talking to
>> "snoopy" it is always someone well defined - same as the last time -
>> without awareness of who that person *actually* is.
>>
>> Alternatively, the server might allow handles to be used on a fcfs basis
>> per conference. Or it might allow handles to be non-unique, so that you
>> could have two "snoopy"s at the same time, bound to unrelated users.
>>
>> Henry - what sort of mechanism did you have in mind for these anonymous
>> participants to identify themselves to one another? Are you talking
>> about the exchange of credentials using the server as an intermediary in
>> the exchange? Or did you have in mind an exchange outside the server.
>> (E.g. Bob establishes a secure connection to Alice and over it tells her
>> "I'm anon2 in conference foo right now"?
>>
>> Thanks,
>> Paul
>>
>>> Thanks, Henry
>>>
>>>
>>> On 8/10/11 9:16 AM, "Harald Alvestrand"<[e-mail]>   wrote:
>>>
>>>> In draft-ietf-rtcweb-use-cases-and-requirements, I would like to extend
>>>> one part of the scenario "4.3.3 Video conferencing system with central
>>>> server".
>>>>
>>>> I would like to add one more paragraph:
>>>>
>>>> "All participant are authenticated by the central server, and authorized
>>>> to connect to the central server. The participants are identified to
>>>> each other by the central server, and the participants do not have
>>>> access to each others' credentials such as e-mail addresses or login IDs".
>>>>
>>>> This is necessary in order to drive use cases that resemble Google
>>>> Hangout, where it is a requirement that people are able to participate
>>>> without disclosing their Google login IDs to each other.
>>>> (in the particular case of Hangout, the display name on their profile
>>>> *is* disclosed ... but that's a different matter)
>>>>
>>>> The reason I think this is important is that it feeds directly into the
>>>> discussion of what WebRTC needs to authorize: The final source or
>>>> destination of media, or the identity of the handler at the first hop.
>>>> In at least the case of Hangouts, the requirement is to *not* authorize
>>>> the final source or destination.
>>>>
>>>> Not sure yet how to formulate that as a requirement, and not sure yet if
>>>> it applies to the cases without a central server, such as 4.2.6. We may
>>>> have to decide.
>>>>
>>>>                            Harald
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb