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

[Paul Kyzivat <[e-mail]>]

On 8/11/11 7:01 PM, Igor Faynberg wrote:
> Yes, definitely, this is a good course of action--to discuss it with the
> authors.
>
> To this end, I will piggy-back another question.
>
> Do I understand it right that an endpoint would need to share a secret
> with every other endpoint it would need to authenticate or be
> authenticated by? If not, how could DH exchange be authenticated (to
> avoid MiTM)?

Related question:

If the trusted server is a conference focus, and there is a single media 
stream between each participant and the focus, how is this secret 
exchange managed? each thing you send over that media stream is 
presumable mixed or otherwise distributed to all the other participants.

	Thanks,
	Paul

> Igor
>
> On 8/11/2011 5:09 PM, Henry Sinnreich wrote:
>> > 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
>>
>>