Subject: RE: RE: Re: [Sipping] Conference-id header?

From: "Arjun Roychowdhury" <[email-masked]>
Date: Fri, 6 Jun 2003 16:41:15 -0400

Victor, I think we are speaking past each other in some issues - I 
apologize if my mail was not clear (I have this problem often :-).

With respect to the conference-ID, what I interpreted from the previous 
mail was that you were concerned that if a person
got to know a conference identifier, he could enter any conference. What I 
suggested was that whether a user is _allowed_
to enter a given conference, does not necessarily have to depend _only_ on 
the ID being provided. Similar to regular SIP calls,
if you are worried about authentication, you will not soley rely on 
conference-id being the only means of identification. Therefore,
even if rogueA got the ID of a particular conference, his INVITE may be 
challenged by a participant who its sent to with this identification.
The above does not really depend on whether a conference is meshed or 
centralized.

For example, in the paper that Jonathan L. subsequenty posted 
(http://www1.cs.columbia.edu/~lennox/fullmesh.pdf), he has suggested
a public key mechanism for the end-system (which either stays for one 
conference, or longer , as his footnote suggests). That to me
is a better mechanism for user verification than trying to make the 
conf-uri non-traceable/guessable.

Back to your original Q:

I do agree, that one does need a unique conference-identifier, and no such 
standard method/header  has been specified today. 

Now Ill shut up :-)

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860 

"Victor A Paulsamy" <[email-masked]>
06/06/2003 04:04 PM
Please respond to victor

        To:     "'Arjun Roychowdhury'" <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>
        Subject:        RE: RE: Re: [Sipping] Conference-id header?

Arjun,

Thanks for the thoughts, inline ...

-----Original Message-----
>From: Arjun Roychowdhury [mailto:[email-masked]] 

>ARC> I feel we are mixing two things here. 'Computing' or 'intercepting' 
a 
>conference-ID should
>have nothing to do with being able to attack an existing conference. 

>To me, being able to 'get' a conference ID simply tells you that a 
>conference is being hosted here.
>It does not necessarily allow you to enter one. 

A full-mesh conferencing starts off with a simple two party call. Consider
that UAC is inviting a new user or the new user contacts UAC. The UAC 
grants
the new user a conference membership by choosing a conference id and 
passing
it over to the new one along with UAS's AOR. 

Since the new one gained a membership, it sends the UAS (assume that it 
know
this id by some means) a request to join the conference that contains this
id. The UAS can infer, from the id, that the new one is a member of the
conference and this request cannot be declined (to set up a full-mesh).
Otherwise, it's up to the UAS to grant it a membership.

Hence, a conference-id, indeed, allows one to enter a specific conference,
in full-mesh. Unlike, a conference-uri, it's non-routable (it doesn't 
deduce
to any particular UA). This is the right thing, because every one has to
establish a dialog with every one else (no central controller).

>With respect to your comment of mandating a conference-id for a full-mesh 

>conference, Ill leave it to the experts
>here to comment on that -> Ive never thought much into full-mesh 
>scenarios.

For the aforementioned reason, it has to be mandated.

Regards,

--victor

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Victor A Paulsamy" <[email-masked]>
Date: Fri, 6 Jun 2003 14:44:07 -0700

>The above does not really depend on whether a conference is meshed or 

Agreed.

>conf-uri non-traceable/guessable.

Me too! And that's why I touched upon the problems of both guessable and
non-guessable ids in one of the previous posts.

Now, it's time for me to go!

Regards,

--victor

---

From: "Victor A Paulsamy" <[email-masked]>
Date: Fri, 6 Jun 2003 15:01:31 -0700

>the ID being provided. Similar to regular SIP calls,

What I tried to convey was that, in a full-mesh, the id suggests to the
recipient that the sender is a party to the conference and hence, this
request has to be acceded to, based on the results of authentication.

Hope things are clear, now.

Regards,

--victor