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

Alan Johnston <alan.b.johnston@gmail.com> Fri, 12 August 2011 15:57 UTC

Return-Path: <alan.b.johnston@gmail.com>
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 5340021F854E for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 08:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.54
X-Spam-Level:
X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 CQOmwsUVL5Kv for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 08:57:13 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E87ED21F850B for <rtcweb@ietf.org>; Fri, 12 Aug 2011 08:57:12 -0700 (PDT)
Received: by ywm21 with SMTP id 21so2249052ywm.31 for <rtcweb@ietf.org>; Fri, 12 Aug 2011 08:57:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zr7AMKkAoSYSiA7ixWxXBYwJYnomjTa9qFIDaRtDHDg=; b=T+lCKwOwNDaHlEB7hJb01T2GmeZuNzF7idDLY7ZZXDfIysUADifPDxkSrf4BcYoAtm 95dNsKzCF6x+5WeDdxBxxTGHhm2TVs8PSiyDRcs/WoAW3wMfTFCiYGtQBVloZ+vKtdJy JkuTkUK3XHjzqZf6oAmQySZjeApayuzQ8cSP0=
MIME-Version: 1.0
Received: by 10.151.25.13 with SMTP id c13mr2201002ybj.208.1313164670095; Fri, 12 Aug 2011 08:57:50 -0700 (PDT)
Received: by 10.150.140.4 with HTTP; Fri, 12 Aug 2011 08:57:50 -0700 (PDT)
In-Reply-To: <4E454A35.1020207@alum.mit.edu>
References: <CA69AF47.1CBB0%henry.sinnreich@gmail.com> <4E445F49.6080705@alcatel-lucent.com> <4E449E6B.8020205@alum.mit.edu> <4E450F00.9090908@alvestrand.no> <4E454A35.1020207@alum.mit.edu>
Date: Fri, 12 Aug 2011 10:57:50 -0500
Message-ID: <CAKhHsXF7WpQc8=h0VunJpRrNyRg_0dYZ5C6XypvNHjb3RMBoKA@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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:57:14 -0000

ZRTP is much more about media privacy than authentication.  The SRTP
key agreement can be authenticated by checking the SAS out of band,
but this doesn't really tell you who you are talking to, just that
there is no MiTM.  If a shared secret has been cached from a previous
call, then you can tell that it is the same person you talked to
previously, but again, it doesn't say who.  If an end-to-end integrity
protected signaling path was used, you can verify that you are talking
to the other signaling entity, whatever identity that provides.

For a conference call, if the media flows are full mesh
(peer-to-peer), then you could use ZRTP to authenticate each leg of
the conference, although this would be cumbersome.  For a centrally
mixed conference, each media stream is between a participant and the
mixer/focus, who is not a human, so the SAS approaches are out, and
each participant will have a different SAS, so comparing them isn't
possible.

- Alan -

On Fri, Aug 12, 2011 at 10:43 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 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
>>>
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>