Subject: [Simple] Anonymous participants in a chat room

From: Geir Arne Sandbakken <[email-masked]>
Date: Wed, 02 Dec 2009 14:49:46 +0100

Paul,

I split this specific issue out from the WGLC thread, as it need a bit 
more attention.

You called for a clear spell out behavior for having anonymous 
participants in a chat room.  IMHO the only difference between a focus 
with chat compared to a focus supporting other media, is that the MSRP 
switch utilizes the anonymous URI to switch the messages.  Any mechanism 
supported by a focus for anonymous participation is valid for chat.  I 
see the problem to be general for SIP based conferencing.

Two possible ways to solve this:
1. Describe one normative way to have anonymous participants in a 
conference focus.
2. Do not describe the anonymity mechanism itself, but add a requirement 
that the URI used to route the message must be anonymous.

Thanks,
Geir Arne

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Dec 2009 09:33:58 -0500

> that the URI used to route the message must be anonymous.

Geir,

Yeah, you are right that in principle there is nothing special about 
anonymous participation here. So potentially this draft could say 
nothing at all. I guess I was reacting to its attempt to say something, 
yet leaving it unclear what was being proposed.

In a typical anonymous call, the callee does not know the identity of 
the caller. If this is applied to a conference, that means that neither 
the focus nor any of the other participants know the identity of that 
participant.

But I think what you were hinting at was a situation where the focus 
*does* know the identity of a participant, yet provides a way to hide 
that identity from the other participants. This case *is* different from 
other media (at least the common ones). The other media don't expose 
URIs of the sending party in the media stream, and the actual source of 
the media is lost in the mixing process. So its only a matter of hiding 
the identity in the conference event package that is required.

Here the problem is more difficult. The From URI in the CPIM wrapper is 
being constrained to match the one used by the "anonymous" user to 
connect to the focus, and will be exposed to the other participants. Yet 
if the participant uses an anonymous URI to establish the connection it 
may not be able to authenticate as a valid participant in the conference.

What needs to be described depends on the goals. If the only goal is to 
permit participants that are anonymous to the focus, then little needs 
to be said. But if the goal is for the focus to know the identity of a 
participant, yet permit that identity to be hidden from other 
participants, then a mechanism to achieve that needs to be spelled out.

(For instance it could call for the MSRP switch to do the anonymizing, 
by replacing the From address in the CPIM wrapper. Or it could be done 
by negotiating an anonymous URI for the participant to include in the 
MSRP, that is different from the URI used to establish the dialog with 
the focus.)

	Thanks,
	Paul

---

From: Geir Arne Sandbakken <[email-masked]>
Date: Wed, 02 Dec 2009 17:33:12 +0100

Paul,

An earlier revision of the draft tried to replace the real URI's with 
anonymous ones.  Remove them both from the MSRP headers and in the 
conference event package. The issue was keeping the client and the focus 
in sync - so a client didn't send a message to itself not knowing it's 
own anonymous URI.  Listening in on the conference event package trying 
to discover it was just to tenuous.

The proposed solution to the problem was to register with the focus in 
order to receive a temporary GRUU. Both the client and the focus would 
know the binding - and the client could use it as a normal URI in the 
CPIM wrapper.  As you have noticed the current drafts hints about this - 
but doesn't require it.  This just makes things unclear.

While I would like to see a solution to the problem, I propose that the 
hint is removed.  Instead add some non-normative text referring to a 
temporary GRUU as a good example of an anonymous URI that would fulfill 
the requirements of an anonymous participant.

Before:
Anonymous URI:  a temporary Globally Routable User Agent URI (GRUU)
      [I-D.ietf-sip-gruu] that can be registered with the conference
      focus to conceal a participant's SIP AOR from the other
      participants in the conference.

New (with non-English-speaker-disclaimer):
Anonymous URI:  a URI concealing the
       participant's SIP AOR from the other participants
       in the conference.  It is the URI of which the participant
       is known to the focus and the MSRP switch. A temporary GRUU
       is an example of such a URI.

..and change the following references to this new definition.

Thanks,
Geir Arne

Paul Kyzivat wrote:
>> I split this specific issue out from the WGLC thread, as it need a 
>> bit more attention.
>>
>> participants in a chat room.  IMHO the only difference between a 
>> focus with chat compared to a focus supporting other media, is that 
>> the MSRP switch utilizes the anonymous URI to switch the messages.  
>> Any mechanism supported by a focus for anonymous participation is 
>> valid for chat.  I see the problem to be general for SIP based 
>> conferencing.
>>
>> 2. Do not describe the anonymity mechanism itself, but add a 
>> requirement that the URI used to route the message must be anonymous.
>
> Geir,
>
> nothing at all. I guess I was reacting to its attempt to say 
> something, yet leaving it unclear what was being proposed.
>
> the caller. If this is applied to a conference, that means that 
> neither the focus nor any of the other participants know the identity 
> of that participant.
>
> that identity from the other participants. This case *is* different 
> from other media (at least the common ones). The other media don't 
> expose URIs of the sending party in the media stream, and the actual 
> source of the media is lost in the mixing process. So its only a 
> matter of hiding the identity in the conference event package that is 
> required.
>
> Here the problem is more difficult. The From URI in the CPIM wrapper 
> is being constrained to match the one used by the "anonymous" user to 
> connect to the focus, and will be exposed to the other participants. 
> Yet if the participant uses an anonymous URI to establish the 
> connection it may not be able to authenticate as a valid participant 
> in the conference.
>
> What needs to be described depends on the goals. If the only goal is 
> to permit participants that are anonymous to the focus, then little 
> needs to be said. But if the goal is for the focus to know the 
> identity of a participant, yet permit that identity to be hidden from 
> other participants, then a mechanism to achieve that needs to be 
> spelled out.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Dec 2009 13:45:35 -0500

> to discover it was just to tenuous.

OK, I understand how that could be a problem.

> but doesn't require it.  This just makes things unclear.

Yup.

>       is an example of such a URI.

I don't see how this helps. Its not enough for anyone to implement 
anything interoperable.

ISTM that the properties you are looking for in this URI are:
- it can be used in the From and To of CPIM bodies
   to refer to a participant
- sip messages sent to this URI will not reach the participant,
   and ideally are never complete successfully.
- the URI can only be mapped to the actual URI of the participant
   using secret knowledge only known to the focus and switch.

A GRUU, even if assigned by the focus itself, doesn't have this 
property, since sip messages sent to it would presumably succeed.
Now that *may* be acceptable, if it is only true for the lifetime of the 
connection to the focus, but its not ideal. (I guess the gruu *could* 
have those properties if the proxy issuing the gruu refuses to route any 
out of dialog requests to it. But that would make it *special*. If the 
UA wants such properties for the gruu then it would need some way to 
negotiate that behavior when requesting the gruu.)

If you want to finish this up without solving the problem, you might as 
well just say that a mechanism by which a participant may conceal its 
identity from other participants is left for future work.

I guess it might also be useful to suggest that using a temporary gruu 
could provide a degree of anonymity, but would only work if the focus 
permits unknown participants to join, or authenticates callers with a 
mechanism independent of the From address. (E.g. Digest.) And this would 
also expose the UA to incoming sip requests to that gruu from sources 
other than the conference. (It could however refuse such requests.)

	Thanks,
	Paul

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

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 4 Dec 2009 01:41:57 +1100

(apologies, the conversation accidentally became private when I hit the
reply button. CCing the list again).

2009/12/4 Paul Kyzivat <[email-masked]>

> (Did you mean this reply to be only to me? If not, feel free to forward to
> Geir and the list.)
>
>
> Hisham Khartabil wrote:
>
>> I would suggest saying that the method of obtaining an anonymous URI is
>> out of scope of this document, but the anonymous URI must allow messages to
>> be routed to the owner. Non-normative text suggesting during the user's
>> domain to obtain a gruu.
>>
>
Can't remember what I was trying to say here, but it sure doesn't make sense
(dam sensitive mouse pad). I think I suggesting non-normative text to the
effect of what I have below (next comment).

>
>> I.e.
>>
>> - you join the conference using the anonymous URI
>> - the focus only knows you anonymous uri and sends messages to it
>> - it is the user's responsibility to make sure that this anonymous uri
>> routes to it (perhaps using the user's domain to obtain a gruu)
>>
>> Regarding authentication, conferences either authenticate using a PIN or
>> username and password. The username and password are usually entered by the
>> creator of the conference or by the user registering (not sip registration)
>> on a website. Either case, you need to know your anonymous URI before you
>> get registered.
>>
>
> Knowing your anonymous URI before you sign up to participate in the
> conference may be a problem, assuming you might do that hours/days/weeks in
> advance.
>

Can you elaborate what the problem might be?

I can go into a webpage and create an account that enables me to join
chatroom using my anonymous uri [email-masked] and a password of
my choosing. This anonymous URI could be gruu or could be a service that my
domain offers.

The point is that it doesn't matter. The draft needs to say, imo, that the
method of obtaining an anonymous URI is out of scope of this document, but
the anonymous URI must allow messages to be routed to the owner.

Regards,
Hisham

>
> I guess its not a problem for those conferences that simply use a password
> or pin and allow anybody who knows that. Its the same as when people call
> into audio conferences from arbitrary phone numbers.
>
> And it could work if you enrolled for a conference using your true identity
> and were given a unique id/pw with which to authenticate, but which is
> distinct from the From URI you use to connect. That is roughly the same as
> using digest authentication.
>
> What is important here is to spell out anything "special" that the UA needs
> to do.
>
>        Thanks,
>        Paul
>
>  Hisham
>>
>> 2009/12/3 Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
>>
>>
>>
>>
>>        An earlier revision of the draft tried to replace the real URI's
>>        with anonymous ones.  Remove them both from the MSRP headers and
>>        in the conference event package. The issue was keeping the
>>        client and the focus in sync - so a client didn't send a message
>>        to itself not knowing it's own anonymous URI.  Listening in on
>>        the conference event package trying to discover it was just to
>>        tenuous.
>>
>>
>>        The proposed solution to the problem was to register with the
>>        focus in order to receive a temporary GRUU. Both the client and
>>        the focus would know the binding - and the client could use it
>>        as a normal URI in the CPIM wrapper.  As you have noticed the
>>        current drafts hints about this - but doesn't require it.  This
>>        just makes things unclear.
>>
>>
>>    Yup.
>>
>>
>>        While I would like to see a solution to the problem, I propose
>>        that the hint is removed.  Instead add some non-normative text
>>        referring to a temporary GRUU as a good example of an anonymous
>>        URI that would fulfill the requirements of an anonymous
>> participant.
>>
>>        Before:
>>    Now that *may* be acceptable, if it is only true for the lifetime of
>>    the connection to the focus, but its not ideal. (I guess the gruu
>>    *could* have those properties if the proxy issuing the gruu refuses
>>    to route any out of dialog requests to it. But that would make it
>>    *special*. If the UA wants such properties for the gruu then it
>>    would need some way to negotiate that behavior when requesting the
>>    gruu.)
>>
>>    If you want to finish this up without solving the problem, you might
>>    as well just say that a mechanism by which a participant may conceal
>>    its identity from other participants is left for future work.
>>
>>    I guess it might also be useful to suggest that using a temporary
>>    gruu could provide a degree of anonymity, but would only work if the
>>    focus permits unknown participants to join, or authenticates callers
>>    with a mechanism independent of the From address. (E.g. Digest.) And
>>    this would also expose the UA to incoming sip requests to that gruu
>>    from sources other than the conference. (It could however refuse
>>    such requests.)
>>
>>           Thanks,
>>           Paul
>>
>>
>>                I split this specific issue out from the WGLC thread, as
>>                it need a bit more attention.
>>
>>                You called for a clear spell out behavior for having
>>                anonymous participants in a chat room.  IMHO the only
>>                difference between a focus with chat compared to a focus
>>                supporting other media, is that the MSRP switch utilizes
>>                the anonymous URI to switch the messages.  Any mechanism
>>                supported by a focus for anonymous participation is
>>                valid for chat.  I see the problem to be general for SIP
>>                based conferencing.
>>
>>                1. Describe one normative way to have anonymous
>>                participants in a conference focus.
>>                2. Do not describe the anonymity mechanism itself, but
>>                add a requirement that the URI used to route the message
>>                must be anonymous.
>>
>>
>>            Geir,
>>
>>            Yeah, you are right that in principle there is nothing
>>            special about anonymous participation here. So potentially
>>            this draft could say nothing at all. I guess I was reacting
>>            to its attempt to say something, yet leaving it unclear what
>>            was being proposed.
>>
>>            In a typical anonymous call, the callee does not know the
>>            identity of the caller. If this is applied to a conference,
>>            that means that neither the focus nor any of the other
>>            participants know the identity of that participant.
>>
>>            But I think what you were hinting at was a situation where
>>            the focus *does* know the identity of a participant, yet
>>            provides a way to hide that identity from the other
>>            participants. This case *is* different from other media (at
>>            least the common ones). The other media don't expose URIs of
>>            the sending party in the media stream, and the actual source
>>            of the media is lost in the mixing process. So its only a
>>            matter of hiding the identity in the conference event
>>            package that is required.
>>
>>            Here the problem is more difficult. The From URI in the CPIM
>>            wrapper is being constrained to match the one used by the
>>            "anonymous" user to connect to the focus, and will be
>>            exposed to the other participants. Yet if the participant
>>            uses an anonymous URI to establish the connection it may not
>>            be able to authenticate as a valid participant in the
>>            conference.
>>
>>            What needs to be described depends on the goals. If the only
>>            goal is to permit participants that are anonymous to the
>>            focus, then little needs to be said. But if the goal is for
>>            the focus to know the identity of a participant, yet permit
>>            that identity to be hidden from other participants, then a
>>            mechanism to achieve that needs to be spelled out.
>>
>>            (For instance it could call for the MSRP switch to do the
>>            anonymizing, by replacing the From address in the CPIM
>>            wrapper. Or it could be done by negotiating an anonymous URI
>>            for the participant to include in the MSRP, that is
>>            different from the URI used to establish the dialog with the
>>            focus.)
>>
>>               Thanks,
>>               Paul
>>
>>
>>        [email-masked] <mailto:[email-masked]>
>>
>>    [email-masked] <mailto:[email-masked]>
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 07:58:44 -0700

On 12/3/09 7:41 AM, Hisham Khartabil wrote:

> chatroom using my anonymous uri [email-masked]
> <mailto:[email-masked]> and a password of my choosing. This
> anonymous URI could be gruu or could be a service that my domain offers.
> 
> The point is that it doesn't matter. The draft needs to say, imo, that
> the method of obtaining an anonymous URI is out of scope of this
> document, but the anonymous URI must allow messages to be routed to the
> owner.

The question is: does the chatroom then need to take further measures to
hide the identifier from everyone in the room (including the admins)?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Dec 2009 11:11:42 -0500

Inline...

Hisham Khartabil wrote:
> 2009/12/4 Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> 
>     (Did you mean this reply to be only to me? If not, feel free to
>     forward to Geir and the list.)
> 
> 
>     Hisham Khartabil wrote:
> 
>         I would suggest saying that the method of obtaining an anonymous
>         URI is out of scope of this document, but the anonymous URI must
>         allow messages to be routed to the owner. Non-normative text
>         suggesting during the user's domain to obtain a gruu.
> 
> 
> Can't remember what I was trying to say here, but it sure doesn't make 
> sense (dam sensitive mouse pad). I think I suggesting non-normative text 
> to the effect of what I have below (next comment).
>  
> 
> 
>         I.e.
> 
>         - it is the user's responsibility to make sure that this
>         anonymous uri routes to it (perhaps using the user's domain to
>         obtain a gruu)
> 
>         Regarding authentication, conferences either authenticate using
>         a PIN or username and password. The username and password are
>         usually entered by the creator of the conference or by the user
>         registering (not sip registration) on a website. Either case,
>         you need to know your anonymous URI before you get registered.
> 
>     conference may be a problem, assuming you might do that
>     hours/days/weeks in advance.
> 

The problem is that the lifetime of the anonymous URI might well be 
limited. For instance, a temporary GRUU might only be valid for the 
lifetime of one registration and its renewals. If I register again later 
(perhaps with a different contact) the old one may no longer work.

> document, but the anonymous URI must allow messages to be routed to the 

I agree that how you get this URI need not be specified.

But to allow for limited lifetime anonymous URIs, the mechanism for 
authenticating that you are a valid participant of the conference ought 
to be decoupled (or decouplable) from the specific URI you are using to 
connect.

But I guess this need not be normative either. It may simply be a QOI 
(quality of implementation) issue. Still, it might be worth noting, even 
if non-normatively.

	Thanks,
	Paul

> Regards,
> Hisham
>  
> 
> 
>     I guess its not a problem for those conferences that simply use a
>     password or pin and allow anybody who knows that. Its the same as
>     when people call into audio conferences from arbitrary phone numbers.
> 
>     And it could work if you enrolled for a conference using your true
>     identity and were given a unique id/pw with which to authenticate,
>     but which is distinct from the From URI you use to connect. That is
>     roughly the same as using digest authentication.
> 
>     What is important here is to spell out anything "special" that the
>     UA needs to do.
> 
>            Thanks,
>            Paul
> 
>         Hisham
> 
>         2009/12/3 Paul Kyzivat <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
> 
> 
> 
> 
>         <mailto:[email-masked] <mailto:[email-masked]>>
> 
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

---

From: Geir Arne Sandbakken <[email-masked]>
Date: Fri, 04 Dec 2009 14:48:36 +0100

Experts,

What about something like

Anonymous URI: a URI concealing the
participant's SIP AOR from the other participants
in the conference. The allocation of such a
URI is out of scope of this specification.
It must be valid for the length of the conference,
and will be utilized by the MSRP switch to
route messages to and from anonymous participants.

.. and I remove any references to temporary GRUU and how to get them.

Thanks,
Geir Arne

Paul Kyzivat wrote:
> Inline...
>
> Hisham Khartabil wrote:
>> (apologies, the conversation accidentally became private when I hit 
>> the reply button. CCing the list again).
>>
>>
>>
>> Can't remember what I was trying to say here, but it sure doesn't 
>> make sense (dam sensitive mouse pad). I think I suggesting 
>> non-normative text to the effect of what I have below (next comment).
>>
>>
>>
>> I.e.
>>
> lifetime of one registration and its renewals. If I register again 
> later (perhaps with a different contact) the old one may no longer work.
>
>> The point is that it doesn't matter. The draft needs to say, imo, 
>> that the method of obtaining an anonymous URI is out of scope of this 
>> document, but the anonymous URI must allow messages to be routed to 
>> the owner.
>
> authenticating that you are a valid participant of the conference 
> ought to be decoupled (or decouplable) from the specific URI you are 
> using to connect.
>
> (quality of implementation) issue. Still, it might be worth noting, 
> even if non-normatively.
>
> Thanks,
> Paul
>
>> Regards,
>> Hisham
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Dec 2009 08:58:29 -0500

I'm ok with that.

	Thanks,
	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Sat, 5 Dec 2009 14:21:20 +1100

I'm ok with that too.

2009/12/5 Paul Kyzivat <[email-masked]>

>>>> sense (dam sensitive mouse pad). I think I suggesting non-normative text to
>>>> the effect of what I have below (next comment).
>>>>
>>>>
>>>>
>>>> I.e.
>>>>
>>> limited. For instance, a temporary GRUU might only be valid for the lifetime
>>> of one registration and its renewals. If I register again later (perhaps
>>> with a different contact) the old one may no longer work.
>>>
>>>> chatroom using my anonymous uri [email-masked] <mailto:
>>>> [email-masked]> and a password of my choosing. This anonymous
>>>> URI could be gruu or could be a service that my domain offers.
>>>>
>>>> the method of obtaining an anonymous URI is out of scope of this document,
>>>> but the anonymous URI must allow messages to be routed to the owner.
>>>>
>>>
>>> authenticating that you are a valid participant of the conference ought to
>>> be decoupled (or decouplable) from the specific URI you are using to
>>> connect.
>>>
>>> (quality of implementation) issue. Still, it might be worth noting, even if
>>> non-normatively.
>>>
>>> Thanks,
>>> Paul
>>>
>>>  Regards,
>>>> Hisham
>>>>
>>>>
>>>>