Subject: [clue] Unauthenticated participants

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2015 08:16:08 -0400

Followup to discussion in session today:

A question came up about whether participants must be authenticated. 
IIUC the answer is no. At the least, there could be participants into a 
conference who don't support clue and aren't authenticated, while other 
participants do support clue.

When the focus sends out an advertisement, all the participant info in 
that advertisement is an assertion by it. So when I receive an 
advertisement I base my trust in it on my level of trust in the 
advertiser. If the focus is forwarding participant info that it received 
in advertisements from other participants, then it ought to vet that 
info before passing it on.

It could be useful to add a property to the participant info indicating 
whether the participant has been authenticated. With appropriate words, 
this could allow the focus to forward along participant properties even 
when it cannot vouch for them.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Mon, 20 Jul 2015 18:20:31 +0300

Hi Paul,
One more point that I forgot during the session is that we have an issue
about whom are we authenticating. The CLUE system or the user.
If the user comes to a conference room and just uses a system than there is
no user to authenticate.
Authentication can happen if he registers with the Tele-presence system.  So
we either authenticate the system or are unable to authenticate. I will
write some text about this issue in the security section
Roni

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, July 20, 2015 3:16 PM
To: CLUE
Subject: [clue] Unauthenticated participants

When the focus sends out an advertisement, all the participant info in that
advertisement is an assertion by it. So when I receive an advertisement I
base my trust in it on my level of trust in the advertiser. If the focus is
forwarding participant info that it received in advertisements from other
participants, then it ought to vet that info before passing it on.

It could be useful to add a property to the participant info indicating
whether the participant has been authenticated. With appropriate words, this
could allow the focus to forward along participant properties even when it
cannot vouch for them.

	Thanks,
	Paul

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2015 11:33:26 -0400

> write some text about this issue in the security section

Ultimately we are authenticating the UA. It may be for a room with lots 
of people, or for a focus, or a UA for an individual user. Doesn't 
matter. What matters is how much trust we put into the content of the 
advertisements received from that UA.

It is of special concern for a focus. A focus will typically send out 
advertisements that are constructed, in part, from information it 
receives from other connected UAs. That information can come both from 
received advertisements and from sip signaling.

If the focus has an unauthenticated UA attached, it could severely 
restrict what it says about that. (It could just include the streams 
received, without any identification.)

OTOH, even in that case it could be useful to include more, even if it 
isn't trusted. For instance, for a non-clue client it might want to 
create a scene and identify it based on the From. For an unauthenticated 
clue UA it might want to include some or all of the received 
advertisement. But in these cases there ought to be an indication to the 
recipients of the advertisement from the focus that this info isn't to 
be trusted.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2015 11:57:47 -0400

Here is an example of what I am talking about:

Assume we have a clue conference server. You go to your clue-enabled TP 
room and connect to a conference on the server. Then I connect to the 
conference from a clue-enabled application on my PC. I then send an 
advertisement to the server offering up my audio and video captures 
within a scene. I attach a vcard to those  asserting that I am John 
Chambers, CEO of Cisco.

The server then constructs its own advertisements to each participant. 
For you it creates an advertisement containing once scene for each of 
the participants other than you, containing (roughly) copies of scenes 
it received in advertisements from the other participants. This includes 
the scene I sent. It also creates one (virtual) scene of its own, where 
the captures are MCCs, referencing captures in the other scenes.

If your system analyzes the advertisement to get labels for the received 
streams, it may label the video received from me as being John Chambers.

Presumably you would get a good chuckle out of that.

If the server was cautious, then it might strip out the vcard info if it 
doesn't trust me. Or it might use some other policy.

If we had an attribute indicating that the info wasn't authenticated, 
then your client might be more judicious about displaying it.

But at the end of the day, the advertisement you get is from the server.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Mon, 20 Jul 2015 20:21:19 +0300

Hi Paul,
You assume that the endpoint has an identity for authentication which is not
always the case
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, July 20, 2015 6:33 PM
To: Roni Even; 'CLUE'
Subject: Re: [clue] Unauthenticated participants

On 7/20/15 11:20 AM, Roni Even wrote:
> Hi Paul,
> One more point that I forgot during the session is that we have an 
> issue about whom are we authenticating. The CLUE system or the user.
> If the user comes to a conference room and just uses a system than 
> there is no user to authenticate.
> Authentication can happen if he registers with the Tele-presence 
> system.  So we either authenticate the system or are unable to 
> authenticate. I will write some text about this issue in the security 
> section

Ultimately we are authenticating the UA. It may be for a room with lots of
people, or for a focus, or a UA for an individual user. Doesn't matter. What
matters is how much trust we put into the content of the advertisements
received from that UA.

It is of special concern for a focus. A focus will typically send out
advertisements that are constructed, in part, from information it receives
from other connected UAs. That information can come both from received
advertisements and from sip signaling.

If the focus has an unauthenticated UA attached, it could severely restrict
what it says about that. (It could just include the streams received,
without any identification.)

OTOH, even in that case it could be useful to include more, even if it isn't
trusted. For instance, for a non-clue client it might want to create a scene
and identify it based on the From. For an unauthenticated clue UA it might
want to include some or all of the received advertisement. But in these
cases there ought to be an indication to the recipients of the advertisement
from the focus that this info isn't to be trusted.

	Thanks,
	Paul

> IIUC the answer is no. At the least, there could be participants into 
> a conference who don't support clue and aren't authenticated, while 
> other participants do support clue.
>
> advertiser. If the focus is forwarding participant info that it 
> received in advertisements from other participants, then it ought to vet
that info before passing it on.
>
> It could be useful to add a property to the participant info 
> indicating whether the participant has been authenticated. With 
> appropriate words, this could allow the focus to forward along 
> participant properties even when it cannot vouch for them.
>
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2015 13:44:17 -0400

> You assume that the endpoint has an identity for authentication which is not

If the endpoint is to authenticate, then either it has an identity of 
its own, or else it "borrows" an identity supplied by a user of the 
device. The effect is the same to the other end.

And if neither is the case, and so it can't authenticate, it still has 
some asserted identity, even if it is Anonymous.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jul 2015 18:45:37 +0300

Hi Paul,
The difference will be with the x-card information, if no user-id it will
say probably the name of the conference room.
One question will be if we allow a room that has no identification to join
as un-authorize, it may be allowed in which case the conference server
should be cautious about what he sends as advertisement to it. This is
something we can mention in the security section
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, July 20, 2015 8:44 PM
To: Roni Even; 'CLUE'
Subject: Re: [clue] Unauthenticated participants

On 7/20/15 1:21 PM, Roni Even wrote:
> Hi Paul,
> You assume that the endpoint has an identity for authentication which 
> is not always the case Roni

If the endpoint is to authenticate, then either it has an identity of its
own, or else it "borrows" an identity supplied by a user of the device. The
effect is the same to the other end.

And if neither is the case, and so it can't authenticate, it still has some
asserted identity, even if it is Anonymous.

	Thanks,
	Paul

> Ultimately we are authenticating the UA. It may be for a room with 
> lots of people, or for a focus, or a UA for an individual user. 
> Doesn't matter. What matters is how much trust we put into the content 
> of the advertisements received from that UA.
>
> create a scene and identify it based on the From. For an 
> unauthenticated clue UA it might want to include some or all of the 
> received advertisement. But in these cases there ought to be an 
> indication to the recipients of the advertisement from the focus that this
info isn't to be trusted.
>> When the focus sends out an advertisement, all the participant info 
>> in that advertisement is an assertion by it. So when I receive an

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jul 2015 18:53:55 +0300

Hi Paul,
I am not sure I understand? All the participants in the examples support
CLUE and were authenticated and later in the advertisement sent some x-card
information that is not true.?
Is there a way to prevent it?  So it allows anyone to claim a role in the
conference or provide some job title? Any suggestions?
Roni

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, July 20, 2015 6:58 PM
To: [email-masked]
Subject: Re: [clue] Unauthenticated participants

Assume we have a clue conference server. You go to your clue-enabled TP room
and connect to a conference on the server. Then I connect to the conference
from a clue-enabled application on my PC. I then send an advertisement to
the server offering up my audio and video captures within a scene. I attach
a vcard to those  asserting that I am John Chambers, CEO of Cisco.

The server then constructs its own advertisements to each participant. 
For you it creates an advertisement containing once scene for each of the
participants other than you, containing (roughly) copies of scenes it
received in advertisements from the other participants. This includes the
scene I sent. It also creates one (virtual) scene of its own, where the
captures are MCCs, referencing captures in the other scenes.

If we had an attribute indicating that the info wasn't authenticated, then
your client might be more judicious about displaying it.

	Thanks,
	Paul

On 7/20/15 8:16 AM, Paul Kyzivat wrote:
> received in advertisements from other participants, then it ought to 
> vet that info before passing it on.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2015 12:14:12 -0400

> say probably the name of the conference room.

I think we may be talking past one another.

If a UA representing a room connects to an MCU, the MCU only knows the 
identity based on what is in the signaling, including authentication, 
and what is in the advertisement from the room. If there is no 
authentication, then all of that information is suspect.

When you say "if no user-id it will probably name the room", I think you 
must be talking about policies of room system - that it allows some 
person in the room to provide authentication information, or else 
authenticates with a default for the room. IMO such policies are not 
within our scope. (It seems equally likely that a room might simply 
connect without authenticating if no user-id is given, or that it might 
*always* connect with its own identity/credentials and give no option 
for user supplied credentials.)

> as un-authorize,

IMO this is not a choice that we should make. This should be a 
deployment policy of individual clue devices.

> it may be allowed in which case the conference server

A warning is a good idea.

But beyond that, the question is whether, if an MCU allows an 
unauthenticated device to connect, is there a way for it to indicate the 
unauthenticated status of the info from that device to be reported to 
the other participants of the conference. This isn't something that was 
considered. But I think it would be a good idea.

I think a possible way to do this would be to add an attribute (boolean: 
'authenticated') about this to the scene attributes.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jul 2015 20:40:10 +0300

Paul,
All this discussion is about what to say in the security section and we need
to say if authentication and authorization is a MUST and if not explain why
not/
Note that part of the advertisement includes the x-card which adds other
security concerns related to the above decision, if we allow un-authorized
users can they get the x-card information?
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2015 7:14 PM
To: Roni Even; 'CLUE'
Subject: Re: [clue] Unauthenticated participants

On 7/22/15 11:45 AM, Roni Even wrote:
> Hi Paul,
> The difference will be with the x-card information, if no user-id it 
> will say probably the name of the conference room.

If a UA representing a room connects to an MCU, the MCU only knows the
identity based on what is in the signaling, including authentication, and
what is in the advertisement from the room. If there is no authentication,
then all of that information is suspect.

When you say "if no user-id it will probably name the room", I think you
must be talking about policies of room system - that it allows some person
in the room to provide authentication information, or else authenticates
with a default for the room. IMO such policies are not within our scope. (It
seems equally likely that a room might simply connect without authenticating
if no user-id is given, or that it might
*always* connect with its own identity/credentials and give no option for
user supplied credentials.)

> One question will be if we allow a room that has no identification to 
> join as un-authorize,

IMO this is not a choice that we should make. This should be a deployment
policy of individual clue devices.

> it may be allowed in which case the conference server should be 
> cautious about what he sends as advertisement to it. This is something 
> we can mention in the security section Roni

But beyond that, the question is whether, if an MCU allows an
unauthenticated device to connect, is there a way for it to indicate the
unauthenticated status of the info from that device to be reported to the
other participants of the conference. This isn't something that was
considered. But I think it would be a good idea.

	Thanks,
	Paul

>>> authenticate. I will write some text about this issue in the 
>>> security section
>>
>> Doesn't matter. What matters is how much trust we put into the 
>> content of the advertisements received from that UA.
>>
>> receives from other connected UAs. That information can come both 
>> from received advertisements and from sip signaling.
>>
>> OTOH, even in that case it could be useful to include more, even if 
>> it isn't trusted. For instance, for a non-clue client it might want 
>> to create a scene and identify it based on the From. For an 
>>> IIUC the answer is no. At the least, there could be participants 
>>> into a conference who don't support clue and aren't authenticated, 
>>> while other participants do support clue.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2015 14:05:14 -0400

> users can they get the x-card information?

ISTM that practically speaking an implementation should have the option 
of allowing unauthenticated peers. Suppose you have a conference that is 
intentionally open to all callers. How do you authenticate them? Also, 
when MCU calls out to participants, how does it authenticate them?

Clearly the info from unauthenticated participants needs to be taken 
with a grain of salt. But they ought to be allowed if policy permits.

So, ISTM that the security section should say that every clue endpoint 
SHOULD authenticate its peer endpoints, with mention that this can be 
overridden by policy. And then have some special considerations for 
peers that have not been authenticated.

But that does put us into a box. What do we say about *how* the peer is 
authenticated? IIRC we currently just punt to basic SIP mechanisms. But 
those are pretty weak - just the digest authentication mechanism. 
Normally that is used at registration time. It could be used between 
clue devices, but would require every one to hold a secret about the 
other. And we would need to figure out how to use it bidirectionally.

An alternate way would be to rely on P-Asserted-ID, but that only works 
in certain environments.

I'd like to have a security person chime in here.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 24 Jul 2015 18:13:39 +1000

> conference or provide some job title? Any suggestions?

I don't see that its much different from today's conferences. I can 
participate and verbally say that I'm John Chambers or hold my business 
card saying John Chambers up to the camera. The MCU will forward that 
information with out caring about the contents. Vcard is just a 
convenient textual way of doing the same thing. I don't think its up to 
the MCU to try to determine whether the contents is correct or not.

Regards, Christian

---

From: Roni Even <[email-masked]>
Date: Fri, 24 Jul 2015 09:11:51 +0000

Hi Christian,
This is just a concern we need to mention in the security section if we allow unauthentcated participants to the conference . It is more about supplying "true" v-card information to all participants even if joined without authentication.
Roni

________________________________________
From: clue [[email-masked]] on behalf of Christian Groves [[email-masked]]
Sent: Friday, July 24, 2015 11:13 AM
To: [email-masked]
Subject: Re: [clue] Unauthenticated participants

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jul 2015 14:11:15 -0400

> This is just a concern we need to mention in the security section if we allow unauthentcated participants to the conference . It is more about supplying "true" v-card information to all participant…

Perhaps something like:

"All descriptive information in an advertisement, including vcards, is 
asserted by the advertiser. Advertisers should vet received information 
before placing it in an advertisement. Consumers of advertisements 
should consider their trust in the advertiser when evaluating that 
information."

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 28 Jul 2015 14:46:16 +1000

Basically "all" the information in an advertisement is asserted by the 
advertising endpoint. Nearly all the information provided in an 
Advertisement would have to be configured by someone. They may input 
different capture area, say the view is a room instead of a table etc. 
How does the advertiser "vet" the information?

Maybe we should take the approach of categorising who can set the 
information as to the level of "trust"?

E.g. The information asserted by an Advertising endpoint may be 
configured by different sources. It is likely that attributes are set by 
the sources below.
Endpoint owner set:
- Point of Capture
- Point on Line of Capture
- Area of Capture
- Mobility of Capture
- Audio Capture Sensitivity Pattern
- Description
- Presentation
- View
- Embedded Text
- Scene Information
- Scale Information
- Scene Description

Participant Set:
- Language
- Person Information
- Person Type
- Priority
- Related to

System set:
- MCC Attributes

For endpoint owner and system set attributes the Consumer should 
consider their trust in the advertiser. For participant set attributes 
the Consumer should consider their trust in the advertiser and be aware 
that the advertiser may not be able verify the information provided to 
it by the participant irrespective of whether the participant has been 
authenticated with the advertising endpoint.

The attributes above could also be represented as a table.

Thoughts?

Regards, Christian

On 25/07/2015 4:11 AM, Paul Kyzivat wrote:
>> This is just a concern we need to mention in the security section if 
>> we allow unauthentcated participants to the conference . It is more 
>> about supplying "true" v-card information to all participants even if 
>> joined without authentication.
>> Roni
>
> Perhaps something like:
>
> asserted by the advertiser. Advertisers should vet received 
> information before placing it in an advertisement. Consumers of 
> advertisements should consider their trust in the advertiser when 
> evaluating that information."
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2015 09:48:43 -0400

Christian,

I'm ok with what you say. but there may be more to say.

Users of an endpoint can only determine their trust in the received 
advertisement based on their trust in the endpoint they are connected 
to. They may or may not know it is an MCU. And if they do know it is an 
MCU, they may not know where it gets its information or how it verifies it.

It may be helpful to say something more about the responsibilities of 
MCUs. In particular, point out when they pass along received information 
they are implicitly endorsing it. So they SHOULD only do so when they 
can verify the identity of the source.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Jul 2015 14:27:48 +1000

Hello Paul,

They're valid points.

Regards, Christian

On 28/07/2015 11:48 PM, Paul Kyzivat wrote:
> to. They may or may not know it is an MCU. And if they do know it is 
> an MCU, they may not know where it gets its information or how it 
> verifies it.
>
> MCUs. In particular, point out when they pass along received 
> information they are implicitly endorsing it. So they SHOULD only do 
> so when they can verify the identity of the source.
>
>     Thanks,
>     Paul
>