Re: [rtcweb] Exchange of trusted identities in server-based conferencing (Re: Use case change request: Identity in multiuser calls)

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 12 August 2011 15:43 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7063721F86EE for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 08:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level:
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjZqtYZkHK9M for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 08:43:14 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 34D8221F86DD for <rtcweb@ietf.org>; Fri, 12 Aug 2011 08:43:14 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id KTiS1h0051ei1Bg53TjsoP; Fri, 12 Aug 2011 15:43:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id KTjq1h0180tdiYw3kTjr54; Fri, 12 Aug 2011 15:43:52 +0000
Message-ID: <4E454A35.1020207@alum.mit.edu>
Date: Fri, 12 Aug 2011 11:43:49 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
References: <CA69AF47.1CBB0%henry.sinnreich@gmail.com> <4E445F49.6080705@alcatel-lucent.com> <4E449E6B.8020205@alum.mit.edu> <4E450F00.9090908@alvestrand.no>
In-Reply-To: <4E450F00.9090908@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org, Phil Zimmermann <prz@mit.edu>
Subject: Re: [rtcweb] Exchange of trusted identities in server-based conferencing (Re: Use case change request: Identity in multiuser calls)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2011 15:43:19 -0000

On 8/12/11 7:31 AM, Harald Alvestrand wrote:
> [[ Reminder to all: If you discover that you're talking about something
> far away from the original topic of the thread, please CHANGE THE
> SUBJECT LINE! ]]
>
> The normal method of authentication for teleconferences today is that
> people prove they have the conference number (by calling in), and
> recognize each others' voices.
> We have security procedures at Google that depend on people recognizing
> each others' faces (sometimes based on prior meetings, sometimes based
> on matching with pictures).
>
> The digital realm doesn't necessarily have to provide a steel vault
> where the analog realm is satisfied with plywood - or at least, I think
> it is not the best for finishing RTCWEB in a reasonable time if we
> insist that steel vaults be part of the requirements.

AFAIK this thread has evolved from Henry's original question about 
identification of participants in confidential conferences. And perhaps 
the proper answer to that is what you say above. While its an 
interesting theoretical issue, in practice I find even the existing 
minimal security mechanisms to be annoying and almost always 
unnecessary. (We flatter ourselves when we think somebody would be 
interested in hearing our discussions.)

There has been an assertion here that ZRTP is useful for solving this 
problem. I don't know if it is - I have never used ZRTP. But it appears 
that it might be difficult to make work well in a conference. (Or maybe 
this has already been worked out. If so, that's great.)

	Thanks,
	Paul

> Harald
>
> On 08/12/11 05:30, Paul Kyzivat wrote:
>> 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" <igor.faynberg@alcatel-lucent.com>
>>>> 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" <pkyzivat@alum.mit.edu>
>>>> <mailto:pkyzivat@alum.mit.edu> 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"<harald@alvestrand.no>
>>>> <mailto:harald@alvestrand.no> 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
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>