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

[Igor Faynberg <[e-mail]>]

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)?

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
>
>