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

From: Harald Alvestrand <[email-masked]>
Date: Wed, 10 Aug 2011 16:16:18 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Aug 2011 10:51:18 -0400

Harald,

There was a lot of consideration of similar issues in the discussions 
around draft-ietf-simple-chat-*. What I took away is that conferencing 
implementations often want something like this, and they all spin it in 
slightly different ways. I *suspect* that in many cases the differences 
were gratuitous at the start, but that ultimately the chosen semantics 
become entrenched. As a result, it may be necessary to support an 
assortment of identity semantics - some of which may not make a lot of 
sense when looked at closely and critically.

This centered on "nicknames" to be visible in the conference, and to be 
used to support private communication between individuals in the 
conference without disclosing their actual addresses. (I guess the 
display names you mention below may be an instance of this.) We got into 
all sorts of discussions of scope of uniqueness of nicknames.

	Thanks,
	Paul

On 8/10/11 10:16 AM, Harald Alvestrand wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Aug 2011 11:19:23 -0400

> the final source or destination.
Could this be handled by defining this case as a central server which is
the target of the "call", and which provides in response 1 or more video/
audio streams to the caller.  So you're only authenticating the server, and
the server is responsible for stripping and replacing the authentication
info for the forwarded streams.  The conferencing aspect is merely an aspect
of the service the server provides.  It might merge the video streams,
selectively forward them depending on speaker or on preference of the viewer,
and do similar things with audio.

While in theory it's largely covered by the point-to-point case (for example,
a point-to-point call should support multiple streams), a separate
use-case is still useful here since it both highlights conferencing-specific
issues (such as larger numbers of streams, etc).

We should consider ways for a client to indicate how many simultaneous decodes
it's willing/able to handle.  This lets the server be smart about what it
sends (it may be as simple as rejecting video streams on re-negotiation of o/a
- and that may help handle things such as where the number of streams supported
varies with the type of encoding/resolution/frame-rate, or other client-side loads).

For example, as people join a "Hangout", the server would re-negotiate to add
a video/audio pair (using SDP grouping I assume).  If the client can't handle
another one, it could reject the add (or renegotiate to lower the complexity/size
of existing streams, perhaps).  The server might then send the N most "interesting"
streams, or combine streams, etc.  SDP+o/a may not be optimal here but I think it
would get the job done.

Note that this requires the central server to decrypt and re-encrypt the
streams (as I believe Harald's wording above would).

The "and authorized to connect to the central server" I think is unneeded -
that's up to the policy of the server; there's no reason it can't allow
arbitrary (non-authorized) connections if the service/server so choose.
The same for authenticating the users - that's up to the server/service.
One can run encryption without authenticating the users.

-- 
Randell Jesup
[email-masked]

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 11 Aug 2011 13:33:51 +0200

>access to each others' credentials such as e-mail addresses or login IDs".
I think this paragraph makes a lot of sense, and would be happy to add it. However, I’m not 100% convinced that it would add requirements that are in scope for webrtc or rtcweb.

When writing up this use case, the architecture in mind was centred around a web server that carries out the functionality of serving the web app, handling users, authenticating them, authorising them, allowing them to communicate and so on. That web server would control the central (media) server, which in turn is responsible only for establishing connections for RTC with browsers, mixing audio and selecting video between the users (browsers) selected by the web server, etc.

This would mean that user management, including determining what user identity is revealed to others, is controlled by the web server. I guess this is done already today for many services. What we will add is the possibility to communicate using audio and video without plug-ins.

Does this make sense or not?

Stefan

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Aug 2011 13:47:16 +0200

> Does this make sense or not?
This makes sense. I just want it to be explicit.
It's relevant for the discussion EKR brought up about "who do I 
authorize when I say OK to using a camera" - if it's the far end of the 
connection or the service I'm connecting to.

In the centralized server case, with the added text, it's definitely the 
service, and I'd like to keep it that way. So this is text added in 
order to make sure we don't generate a requirement....

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 11 Aug 2011 16:00:03 +0200

OK! Then I think we have the same view. Will you work on the wording, or should we start with the current one? 

Stefan
________________________________________
From: Harald Alvestrand [[email-masked]]
Sent: Thursday, August 11, 2011 1:47 PM
To: Stefan Håkansson LK
Cc: [email-masked]
Subject: Re: [rtcweb] Use case change request: Identity in multiuser calls

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Aug 2011 16:10:41 +0200

> OK! Then I think we have the same view. Will you work on the wording, or should we start with the current one?
I'm happy if you just insert the paragraph I suggested. Feel free to 
wordsmith, though.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Aug 2011 17:08:58 +0200

> and do similar things with audio.
I think parts of that is an implementation strategy for the scenario in 
4.3.3 - it doesn't have to be that way, so we shouldn't define it as 
part of the scenario.
> varies with the type of encoding/resolution/frame-rate, or other 
If we do multiple video streams inside an RTP session, we don't need 
re-negotiation of o/a to add more streams. We might consider the 
proposed extensions in 
draft-westerlund-avtcore-multistream-and-simulcast to add information 
about number of streams to O/A (he suggests that for max backwards 
compatibility, we should assume that no more than one stream per RTP 
session can be handled unless the extension is used, but that might be 
an overly conservative suggestion).

> streams, or combine streams, etc.  SDP+o/a may not be optimal here but 
Hangouts put all the video streams into one RTP session, and all the 
audio streams into another RTP session. Renegotiation would be needed if 
it didn't.
> streams (as I believe Harald's wording above would).
Not necessarily - if key negotiation goes via the server, the server 
could make sure the key used in the server-to-client direction is the 
same key as that used in the client-to-server direction - but if you 
want to put 2 media streams into the same RTP session, and do keying per 
RTP session, the server would have to decrypt-then-encrypt.
> One can run encryption without authenticating the users.
Yup - when I was writing "authorized to connect", I was thinking of 
anonymous/open access as "policy: everyone's authorized". Similarly, 
authentication - not authenticating is usually easier than 
authenticating, so we don't need to add extra text to cover the 
unauthenticated case.
(showing my age: FTP doesn't really do unauthenticated mode; it just has 
the convention that "anonymous" has a blank password....)

                  Harald

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 11 Aug 2011 11:07:03 -0500

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

Thanks, Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2011 12:50:56 -0400

> 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"<[email-masked]>  wrote:
>

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 11 Aug 2011 13:38:32 -0400

+1.

(Incidentally, this IdM model is consistent with the ITU-T Identity 
Management requirements for next generation networks.)

Igor

On 8/11/2011 7:47 AM, Harald Alvestrand wrote:
>> I think this paragraph makes a lot of sense, and would be happy to 
>> add it. However, I’m not 100% convinced that it would add 
>> requirements that are in scope for webrtc or rtcweb.
>>
>> When writing up this use case, the architecture in mind was centred 
>> around a web server that carries out the functionality of serving the 
>> web app, handling users, authenticating them, authorising them, 
>> allowing them to communicate and so on. That web server would control 
>> the central (media) server, which in turn is responsible only for 
>> establishing connections for RTC with browsers, mixing audio and 
>> selecting video between the users (browsers) selected by the web 
>> server, etc.
>>
>> This would mean that user management, including determining what user 
>> identity is revealed to others, is controlled by the web server. I 
>> guess this is done already today for many services. What we will add 
>> is the possibility to communicate using audio and video without 
>> plug-ins.
>>
> authorize when I say OK to using a camera" - if it's the far end of 
> the connection or the service I'm connecting to.
>
> In the centralized server case, with the added text, it's definitely 
> the service, and I'd like to keep it that way. So this is text added 
> in order to make sure we don't generate a requirement....
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 11 Aug 2011 14:11:23 -0500

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

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 11 Aug 2011 15:39:04 -0400

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:
> On 8/11/11 11:50 AM, "Paul Kyzivat"<[email-masked]>  wrote:
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 11 Aug 2011 16:09:43 -0500

> 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" <[email-masked]>
wrote:

>  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/11 11:50 AM, "Paul Kyzivat" <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>> 
>>  
>>>  
>>>> On 8/10/11 9:16 AM, "Harald Alvestrand"<[email-masked]>
>>>> <mailto:[email-masked]>   wrote:
>>>> 
>>>>  
>>>>>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 11 Aug 2011 17:17:06 -0400

On 8/11/2011 11:08 AM, Harald Alvestrand wrote:

>> We should consider ways for a client to indicate how many simultaneous
>> decodes it's willing/able to handle.  This lets the server be smart about what it

My problem with that is that all streams are not equal.  I can handle a lot
more CIF streams than I can HD streams.  So while a suggestion is good, there
should be some way to say "too much", if not before a stream is added, then after
the fact (that might be good to have anyways).

> audio streams into another RTP session. Renegotiation would be needed if
That assumes they all are using the same parameters/payloads (or ones agreed to
in the m= lines of the existing participants).  I'm not 100% sure that's a
valid assumption - and we need to be able to renegotiate at that point anyways
(new person doesn't support an optional codec being used, for example).  But on
the other hand maybe it's simpler to not try to handle all the funny edge cases
here and force/allow the clients to renegotiate if they don't like the state of
the call.

We should think through the case of multiple video sessions in a conference (example:
one for participants, one for presentations, and perhaps even a second camera for
some participants.)  I don't see any blocker here other than properly identifying which
is the "user" video and which is "presentation" and that may be a W3 issue or an
application issue even.

> RTP session, the server would have to decrypt-then-encrypt.

Do we have enough control of the key selection (and the timing of it) to
do that?  Plus, I see that as an optimization - the server knows the key;
whether the keys are the same or different and if it actually decodes and
re-encodes are performance details (though perhaps important ones).

If the server doesn't know the key, we're in an end-to-end exchange scenario
where the server just acts as a forwarder, and the ends will authenticate each
incoming stream separately, and the server has much more limited ability to
interact with the conference.

-- 
Randell Jesup
[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 11 Aug 2011 19:01:29 -0400

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.
>      (I thought that the lawful intercept issue that came up several
>     times is pertinent here.)  But note that this was a parenthetical
>     remark!
>
>      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.
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2011 23:30:51 -0400

> authenticated by? If not, how could DH exchange be authenticated (to

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Aug 2011 13:31:12 +0200

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

                   Harald

On 08/12/11 05:30, Paul Kyzivat wrote:
> 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

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 12 Aug 2011 10:18:14 -0400

On 8/12/2011 7:31 AM, Harald Alvestrand wrote:
> ...
> ...

Is there not a conference code, too?  In all (five or six of them that I 
have used) there was one.  This code is, effectively, a shared secret. 
In the service we use, the conference host can create a new code for 
each meeting.  (One problem with relying on recognizing voices is 
passive intruding: I can join your conference and never say a word.)

Igor

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2011 11:43:49 -0400

> 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

---

From: Alan Johnston <[email-masked]>
Date: Fri, 12 Aug 2011 10:57:50 -0500

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 <[email-masked]> wrote:
> 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.)
>
> 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
>>

---

From: Randell Jesup <[email-masked]>
Date: Fri, 12 Aug 2011 13:26:00 -0400

> passive intruding: I can join your conference and never say a word.)

IMHO that particular level/type of security is not something to be decided by
rtcweb, that's up to the application and server to decide and handle.

At most, I'd suggest an API that lets the application supply a shared secret
(how it's obtained isn't our problem - from the user, from secure email, etc)
to use in generating/validating the keys and/or identities.

-- 
Randell Jesup
[email-masked]