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

From: "Arjun Roychowdhury" <[email-masked]>
Date: Fri, 6 Jun 2003 13:03:01 -0400

-
If available information is used to compose an id, it's an easy guess for 
an attacker who intercepts the transaction.
On the other hand, even if it is computed in the fashion that other 
globally unique headers are, the attacker can still get hold of it!

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. 

Since this is IP, any attacker
can intercept any-thing  unless the message is encrypted end-end (and 
ofcourse, even if its end-end, with significant more difficulty). For 
example, an  attacker can intercept the Call-ID/CS/From/To value of a 
message flowing across. That does not imply he can barge into a call. 
Whether
he can or not depends on the network security implemented.

Also, typically conferences URI _may_ have a variable entity to it  - ie a 
portion of the URI _may_ be computed
as a fn(time,pid,eth0-id), for example. What that means is for a 
particular conference in a domain
hss.hns.com, the first conference may have the URI 
[email-masked] and the next one
may have [email-masked] where the 'user' part is not using 
static data, which makes guessing
a little more challenging.

How you generate a conference URI that handles a conference is not 
specifically defined - it just needs
 to be routable. You can add your own algorithmic inputs to it to make it 
more dynamic based. 

I would expect authorization to be a separate entity -> irrespective of 
the fact that as person
has managed to intercept a conf-id, that user should be authenticated with 
as strong an authentication scheme as appropriate in the designated 
network.

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.

regds
arjun

_______________________________________________
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 13:04:15 -0700

Arjun,

Thanks for the thoughts, inline ...

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

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

>here to comment on that -> Ive never thought much into full-mesh 

For the aforementioned reason, it has to be mandated.

Regards,

--victor