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

[Henry Sinnreich <[e-mail]>]

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

draft-johnston-rtcweb-media-privacy-00 says ZRTP can also support various
other scenarios, but how I understand it, no PBX or any intermediary is
required.
The default scenario is e2e.

Maybe the authors copied here can clarify.

Thanks, Henry



On 8/11/11 2:39 PM, "Igor Faynberg" <[e-mail]>
wrote:

>    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]>
>> <mailto:[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]>
>>>> <mailto:[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
>>  
>