Subject: RE: [mediactrl] Naked SIP or Always Have Control?

From: "Even, Roni" <[email-masked]>
Date: Mon, 26 Jun 2006 11:16:36 +0100

Eric,
I understand the requirement for securing the access to resources on the
MS. In the example you gave there are two separate connections one from
AS 'A' and the other from AS 'B'. The first security point should be on
the AS preventing user 'b' from getting any information about
conferences for which he is not authorized by AS 'B' to access. My
assumption is that AS 'B' was authenticated by the MS and may be
authorized to access and control the conference of 'a'.

Roni

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Chris Boulton
> Sent: Monday, June 26, 2006 1:06 PM
> To: Burger, Eric; [email-masked]
> Subject: RE: [mediactrl] Naked SIP or Always Have Control?
> 
> 
> Each conference.
> 
> Trusted AS 'A' has customer 'a'.  Trusted AS 'B' has customer 'b'.
'b'
> gets 'B' to tap into 'a's conference.  TLS doesn't help at all, as 'B'
> is trusted.
> 
> [Chris Boulton] Yes - I agree - just wanted to make sure that I was
> 'getting' the exact requirement.  As you have already pointed out -
this
> could be very important from a security point of view as well as
having
> useful SLA properties for policy enforcement between customers.
> 
> I wonder exactly where this would fit into the current structure of
the
> framework.  It seems to fit well at the Framework level (as opposed to
> package level) so that it could be leveraged by any 'usage'.  I
suppose
> it would also be an optional feature - for those deployments that
simply
> don't care.
> 
> Chris.
> 
> 
> -----Original Message-----
> From: Chris Boulton [mailto:[email-masked]]
> Sent: Monday, June 26, 2006 2:32 AM
> To: Burger, Eric; [email-masked]
> Subject: RE: [mediactrl] Naked SIP or Always Have Control?
> 
> 
> Back to one or many control channels:
> 
> My biggest problem with one control channel instead of one per
> "conference" is the security aspect.
> 
> I am REALLY concerned about having a control session be able to
> manipulate an existing session.  We need to think long and hard about
> how to securely do that, considering that hijacking or listening in on
a
> conference is a high value target.
> 
> [Chris Boulton] Just to probe a bit further - is this an
Authentication
> or Authorization issue (or both)?  In other words, does this require
the
> actual control channel being secured (there is already an Editors Note
> to add TLS support on the Control channel) or are you thinking that we
> need a mechanism to authorize EACH command per conference/dialog.
> 
> Chris.
> 
> 
> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Sunday, June 25, 2006 3:20 AM
> To: [email-masked]; Burger, Eric;
[email-masked]
> Subject: RE: [mediactrl] Naked SIP or Always Have Control?
> 
> Hi,
> I agree that those are two separate topics.
> As for control channel first - either way will work. The point to
notice
> is that in order to associate a control request with a SIP user you
need
> the SIP dialog to be established. My view here is that since the
control
> channel can be used for multiple sessions and is not related to a
> specific call it may make sense to establish the control channel
> initially. If you want the whole AS to MS to work on ad-hoc bases then
> it is fine to open the control channel when ever you want.
> 
> As for Eric point about working without a control channel, it is a
good
> point, but this will mean that we do not need the AS to MS protocol at
> all so my view is that it is not relevant here
> 
> Roni Even
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-
> > [email-masked]] On Behalf Of [email-masked]
> > Sent: Friday, June 23, 2006 11:53 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [mediactrl] Naked SIP or Always Have Control?
> >
> > Assuming the use of a control channel, I would offer that the
> > clarification is that it can work either way - control channel
before
> or
> > after the first INVITE. Referring back to my June 7 email, I can at
> > least think of some kind of rationale why we'd want to keep it
> flexible.
> > I haven't yet heard any reason to *require* control channel first.
> >
> > The second, parenthetical, part about whether a control channel is
> > needed for IVR or 4240 services is a different question. And I think
a
> > good one.
> >
> > Cheers,
> >
> > Gary
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> Burger,
> > Eric
> > Sent: Friday, June 23, 2006 4:23 PM
> > To: [email-masked]
> > Subject: [mediactrl] Naked SIP or Always Have Control?
> >
> > I think a little clarification could go a long way on whether the
> > control channel needs to be established before the first INVITE hits
> the
> > media server.
> >
> > For enhanced conferencing, I would offer the control channel does
need
> > to be established before the first INVITE.  However, for IVR or
> regular
> > RFC4240 services, clearly we don't need a control channel (possibly
at
> > all).
> >
> > Make sense?
> >
> > --------------------------
> > Ubiquity Software does not control or endorse the content, messages
or
> > information found in this mail list and it specifically disclaims
any
> > liability with regard to these communications.
> > Ubiquity Software reserves the right the restrict access to any
> > communications in violation of the Terms and Conditions of Use for
> this
> > website or as otherwise deemed improper.
> >
> >
> > --------------------------
> > Ubiquity Software does not control or endorse the content, messages
or
> > information found in this mail list and it specifically disclaims
any
> > liability with regard to these communications.
> > Ubiquity Software reserves the right the restrict access to any
> > communications in violation of the Terms and Conditions of Use for
> this
> > website or as otherwise deemed improper.
> 
> --------------------------
> Ubiquity Software does not control or endorse the content, messages or
> information found in this mail list and it specifically disclaims any
> liability with regard to these communications.
> Ubiquity Software reserves the right the restrict access to any
> communications in violation of the Terms and Conditions of Use for
this
> website or as otherwise deemed improper.
> 
> 
> Information contained in this e-mail and any attachments are intended
> for the use of the addressee only, and may contain confidential
> information of Ubiquity Software Corporation.  All unauthorized use,
> disclosure or distribution is strictly prohibited.  If you are not the
> addressee, please notify the sender immediately and destroy all copies
> of this email.  Unless otherwise expressly agreed in writing signed by
> an officer of Ubiquity Software Corporation, nothing in this
> communication shall be deemed to be legally binding.  Thank you.
> 
> --------------------------
> Ubiquity Software does not control or endorse the content, messages or
> information found in this mail list and it specifically disclaims any
> liability with regard to these communications.
> Ubiquity Software reserves the right the restrict access to any
> communications in violation of the Terms and Conditions of Use for
this
> website or as otherwise deemed improper.

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Mon, 26 Jun 2006 11:21:54 +0100

Simple question:

Assuming that all the AS and MS are in the Secure Trusted domain of our
network, how does 'b get to tap into 'a's conference??? 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Even,
Roni
Sent: Monday, June 26, 2006 6:20 AM
To: Chris Boulton; Burger, Eric; [email-masked]
Subject: RE: [mediactrl] Naked SIP or Always Have Control?

Eric,

Roni

'b'
this
having
the
suppose
simply
a
Authentication
the
notice
need
control
good
before
a
need
at
or
any
or
any
this
this

communications in violation of the Terms and Conditions of Use for this