Subject: [MEDIACTRL] Multiple AS Security Issues

From: Eric Burger <[email-masked]>
Date: Tue, 04 Dec 2007 17:56:40 -0800

<individual contributor hat on>

We have two conflicting requirements.  I do not think they need to be in the
requirements draft, but I do think they need to be addressed in the
framework.

The first requirement is that one application server may not accidentally
step on (snoop, kill, modify, etc.) sessions used by another application
server.  Think multi-tenancy.

The second requirement is that an authorized application server may need to
take over the sessions from another application server, in the event of load
sharing or failure.

Going to the solution space, to help frame if we want this, we can:
1. Punt, saying it is administrative.  I.e., we honor requirement #1, and
media server vendors can build proprietary mechanisms (possibly for later
standardization) to allow a second application server to take over for a
first application serer.

2. Put a cookie in the mediactrl PDU to identify the session.  So long as
the control channel is secure (so the cookie doesn't leak out) and we go on
and on ad nauseum about how the cookie has to remain secure as it gets
passed from AS to AS, we probably will get through SECDIR review.  Up to you
to say the cookie is per control channel or per session.

3. Do the H.248 thing and have an explicit "Hey MS, AS2 now gets my
connections" command.

4. Do the MGCP thing and let any yahoo take over the MS.  Well, extend the
concept to do it securely, etc.  Right now I think this would fall into
category 1, above.

Thoughts?

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 5 Dec 2007 03:27:18 +0100

I'd choose option #2, considering a cookie to identify the session is already in
the core framework (the Dialog-ID). However, my doubt is, how much would the
take over affect the existing SIP sessions, both between the AS and the MS, and
between end users and the MS, so that they do not get lost? My guess is that,
in case, a lot of reinvites or the like might take place, so I assume we have
to consider that as well in the security considerations.

Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

Scrive Eric Burger <[email-masked]>:

> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and have
> received this message in error, please immediately return this by email and
> then delete it.
> 
> 

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: "Adnan Saleem" <[email-masked]>
Date: Tue, 4 Dec 2007 21:33:58 -0800

When an AS takes over from a failed AS, the newly active AS
would establish a *new* control channel to the MS and
carry on with the SIP dialogs and media services that
the failed AS was working on. The replication of SIP call
leg states and media services states is between the two
App Servers, which can be accomplished.

Why would we need the same control channel between
newly active AS and MS ?

Adnan

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]] 
Sent: December 4, 2007 6:27 PM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Multiple AS Security Issues

I'd choose option #2, considering a cookie to identify the session is
already in the core framework (the Dialog-ID). However, my doubt is, how
much would the take over affect the existing SIP sessions, both between
the AS and the MS, and between end users and the MS, so that they do not
get lost? My guess is that, in case, a lot of reinvites or the like
might take place, so I assume we have to consider that as well in the
security considerations.

Lorenzo

Dipartimento di Informatica e Sistemistica Universit degli Studi di
Napoli "Federico II"

---

From: Diego B <[email-masked]>
Date: Tue, 04 Dec 2007 22:39:31 +0200

Hi;
I think the first requirement is valid if you make it read only ( remove 
the kill, modify, etc ). the use case
for this is an auditing application running on a different Application 
Server that access the media server with a new control channel and query 
it about existing sessions (belonging to any application server).

Back in chicago when I was reviewing the requirement document I add 3 
new requirements about this issue:
I don't know if anyone of this fall into your points, but we really need 
a way to be able
to "re open" media channels from a different AS.
> There must be a requirement to handle fail-over (AS fail over).
>
> REQ-MCP-xx: An AS shall be able to send a SIP request to the MS to
> change an open session (reINVITE, UPDATE)
> There may be a security consideration here
>
> REQ-MCP-xx: An AS shall be able to re-open failed channels and to 
> instruct the MS to
> send notifications for those channels to this AS.
>
> REQ-MCP-xx: An AS shall be able to query an MS about open sessions
> and get information about them.

Diego Besprosvan (:-:) 
MailVision Ltd.  
mailto:[email-masked] 
sip:[email-masked] 
http://www.mailvision.com

---

From: Eric Burger <[email-masked]>
Date: Tue, 04 Dec 2007 22:48:37 -0800

I can see the SOX <http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act> police
going apesh*t already:

You are a service provider with a media server.  I am an investment banker
with an application server.  I have a trust relationship with you, so you
let me use your media server.  Fair enough, I cannot listen to
conversations.  However, I keep "auditing" the media server, and notice a
ton of conference calls between Company A and Company B.  I figure out a
merger is in discussion, so I manipulate the stock price.

Replace Company A and Company B with spouse and "your best friend."  I am
sure one can think of a ton of other scenarios for which allowing a
different application server to "simply audit" existing sessions is a major,
major privacy breach.

---

From: "Adnan Saleem" <[email-masked]>
Date: Tue, 4 Dec 2007 22:58:51 -0800

Diego,

I agree. These requirements were there for being able to
support AS failover cases, which I agree is an important feature.
Establishing appropriate security boundaries around the MS and/or
secure and properly authenticated sessions between AS and MS is 
also needed if the MS is accesable outside a secure core network.
This is obviously not unique to the MS or AS-MS control interface.

Adnan 

-----Original Message-----
From: Diego B [mailto:[email-masked]] 
Sent: December 4, 2007 12:40 PM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Multiple AS Security Issues

Hi;
I think the first requirement is valid if you make it read only ( remove
the kill, modify, etc ). the use case for this is an auditing
application running on a different Application Server that access the
media server with a new control channel and query it about existing
sessions (belonging to any application server).

Back in chicago when I was reviewing the requirement document I add 3
new requirements about this issue:
I don't know if anyone of this fall into your points, but we really need
a way to be able to "re open" media channels from a different AS.

Diego Besprosvan (:-:) 
MailVision Ltd.  

Eric Burger wrote:
> Notice:  This email message, together with any attachments, may
contain information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated entities,  that may be confidential,  proprietary,
copyrighted  and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error, please
immediately return this by email and then delete it.

---

From: "Adnan Saleem" <[email-masked]>
Date: Tue, 4 Dec 2007 23:07:26 -0800

Without any security/authentication scheme and deploying a MS 
in a network topology where the MS can be accessed by anyone 
from anywhere in the network is certainly inviting Sarbanes-Oxley 
to walk all over you.

Adnan 

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: December 4, 2007 10:49 PM
To: Diego Besprosvan
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Multiple AS Security Issues

I can see the SOX <http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act>
police going apesh*t already:

You are a service provider with a media server.  I am an investment
banker with an application server.  I have a trust relationship with
you, so you let me use your media server.  Fair enough, I cannot listen
to conversations.  However, I keep "auditing" the media server, and
notice a ton of conference calls between Company A and Company B.  I
figure out a merger is in discussion, so I manipulate the stock price.

Replace Company A and Company B with spouse and "your best friend."  I
am sure one can think of a ton of other scenarios for which allowing a
different application server to "simply audit" existing sessions is a
major, major privacy breach.

On 12/4/07 12:39 PM, "Diego B" <[email-masked]> wrote:

> Hi;
> I think the first requirement is valid if you make it read only ( 
> remove the kill, modify, etc ). the use case for this is an auditing 
> I don't know if anyone of this fall into your points, but we really 
> need a way to be able to "re open" media channels from a different AS.
>> change an open session (reINVITE, UPDATE) There may be a security 
>> consideration here
>> 
>> instruct the MS to send notifications for those channels to this AS.
>> 
>> We have two conflicting requirements.  I do not think they need to be

>> in the requirements draft, but I do think they need to be addressed 
>> in the framework.
>> 
>> The first requirement is that one application server may not 
>> accidentally step on (snoop, kill, modify, etc.) sessions used by 
>> another application server.  Think multi-tenancy.
>> 
>> The second requirement is that an authorized application server may 
>> need to take over the sessions from another application server, in 
>> the event of load sharing or failure.
>> 
>> 1. Punt, saying it is administrative.  I.e., we honor requirement #1,

>> and media server vendors can build proprietary mechanisms (possibly 
>> for later
>> standardization) to allow a second application server to take over 
>> for a first application serer.
>> 
>> 2. Put a cookie in the mediactrl PDU to identify the session.  So 
>> long as the control channel is secure (so the cookie doesn't leak 
>> out) and we go on and on ad nauseum about how the cookie has to 
>> remain secure as it gets passed from AS to AS, we probably will get 
>> through SECDIR review.  Up to you to say the cookie is per control
channel or per session.
>> 4. Do the MGCP thing and let any yahoo take over the MS.  Well, 
>> extend the concept to do it securely, etc.  Right now I think this 
>> would fall into category 1, above.
>> 
>> Thoughts?
>> 
>> 
>> copyrighted  and/or legally privileged, and is intended solely for 
>> the use of the individual or entity named in this message. If you are

>> not the intended recipient, and have received this message in error, 
>> please immediately return this by email and then delete it.
>> 
>> 

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: "Diego B" <[email-masked]>
Date: Wed, 5 Dec 2007 09:20:19 +0200

Interesting, thanks for the link :).

My sample was limited to the same domain, or at least that was in my mind.
Auditing packages is not defined yet, but one can define which information
an MS provide in each situation: 1) to AS that owns the session 2) to AS that
do not own the session. If the auditing info is just counters of resources, i.e
how many active dialogs, how many active announcements, and some
properties of those announcement whitout entering in actual details of
which "company" is using those dialogs or sessions ( or conference
rooms ).

But I agree that a security mechanism must be applied around this. And not
give a "wild" access.

 Diego Besprosvan (:-:)
 MailVision Ltd.

---

From: [email-masked]
Date: Wed, 05 Dec 2007 19:15:31 +0100

Hi guys,

isn't this going to be a classical "delegation" problem?

When using digital certificates, you solve this issue (the so-called  
delegation and single sign-on) by issuing proxy certificates. A proxy  
certificate allows the holder of the certificate to act on someone  
else?s behalf. In fact, it?s very similar to the X.509 digital  
certificates, except that it?s not signed by a Certificate Authority;  
it?s signed by an end user. We can be sure that the certificate is  
authentic by checking its signature. I think that a similar solution  
might ne applied to the case in question. Take also in mind that  
delegation can be applied to a subset of the tasks for which the  
original contractor has been allowed.

Simon

Quoting Diego B <[email-masked]>:

>> extend the
>> the use of the individual or entity named in this message. If you   
>> are not the intended recipient, and have received this message in   
>> error, please immediately return this by email and then delete it.
>>
>
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 5 Dec 2007 19:29:11 -0000

[Chris] Framework?  I would have thought this is more in-line with the Architecture document?  The Control Framework provides the tools for A to connect to B + appropriate security (not MS specific).  When you are delving into policies of who can do what it feels to me that this is MediaCtrl and Media Server specific which should sit somewhere else.
 
Chris.

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 5 Dec 2007 14:18:57 -0800

Duh - that's why I had my IC hat on, as I'm brainless.  Yes, I meant
Architecture. 

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 2:29 PM
To: Eric Burger; [email-masked]
Subject: RE: [MEDIACTRL] Multiple AS Security Issues

We have two conflicting requirements.  I do not think they need to be in
the requirements draft, but I do think they need to be addressed in the
framework.

[Chris] Framework?  I would have thought this is more in-line with the
Architecture document?  The Control Framework provides the tools for A
to connect to B + appropriate security (not MS specific).  When you are
delving into policies of who can do what it feels to me that this is
MediaCtrl and Media Server specific which should sit somewhere else.
 
Chris.

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 6 Dec 2007 00:44:01 +0200

Hi,
I see the two requirements as separate issues.

1. Since more then one AS can use one MS the security mechanism MUST enable the protection of the MS resources used by one AS from a second AS not authorized to use those resources.

2. Application requirement that allows one AS to allow access to his resources on the MS to a second AS. This can be done by security token like what Simon suggest bellow.

This should be discussed in the architecture but the second requirement may require some text in the framework

Roni   

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2007 8:16 PM
> To: Diego B
> Cc: [email-masked]
> banker
> am
> remove
> need
> accidentally
> long as
> contain

---

From: "Adnan Saleem" <[email-masked]>
Date: Wed, 5 Dec 2007 15:02:01 -0800

I agree, to capture this in the architecture doc sounds good to me.

Adnan 

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: December 5, 2007 11:29 AM
To: Eric Burger; [email-masked]
Subject: RE: [MEDIACTRL] Multiple AS Security Issues

 
Chris.

---

From: Dan York <[email-masked]>
Date: Thu, 06 Dec 2007 09:59:29 -0800

Okay... newbie-to-the-group question - why would this NOT be captured in
the Requirements document?

Going back to Eric's original message, both of these sound to me like

> take over the sessions from another application server, in the event of load

Why would we NOT put these in a requirements doc?  Seems like they fit
in there to me.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: Eric Burger <[email-masked]>
Date: Thu, 06 Dec 2007 17:04:47 -0800

Then the proposal does not work: if I cannot "write" to another leg, I
cannot take it over.

On 12/4/07 10:58 PM, "Adnan Saleem" <[email-masked]> wrote:

> in the
> need to
> and

---

From: Eric Burger <[email-masked]>
Date: Thu, 06 Dec 2007 17:05:48 -0800

Same domain is outside of scope.  Reminder: this is the *Internet*
Engineering Task Force.  We must assume inter-AS (Administrative System, or
domain) operation.

On 12/4/07 11:20 PM, "Diego B" <[email-masked]> wrote:

>>>> the

---

From: Eric Burger <[email-masked]>
Date: Thu, 06 Dec 2007 17:06:13 -0800

That is what I meant by a cookie.  This exactly.

---

From: Diego B <[email-masked]>
Date: Fri, 07 Dec 2007 19:01:07 +0200

Hi;
This was just a use case example where some
application running on AS1 will need to access data from sessions owned 
by other application
running on the same AS1 or another AS2.

 Diego Besprosvan (:-:)
 MailVision Ltd.

---

From: Diego B <[email-masked]>
Date: Fri, 07 Dec 2007 19:11:10 +0200

Hi;
I may not explained my self correctly.
The proposal was sent as a review to the requirements document before 
Chicago meeting,
the "read only" was just in the *auditing* example.

My proposal was to add the following req to the document, but they may 
need to be edited
to include more security considerations, and maybe to reword them.

Where those reqs belong (requirements or architecture document).
In my opinion the requirement document must take
into consideration Fail-over.
The architecture doc can then provide the rigth framework ( with security ).

Diego Besprosvan (:-:)
MailVision Ltd. 

Eric Burger wrote:
>>> step on (snoop, kill, modify, etc.) sessions used by another
>>>       
>> application
>>     
>>> take over the sessions from another application server, in the event
>>>       
>> of load
>>     
>>> sharing or failure.
>>>
>>> media server vendors can build proprietary mechanisms (possibly for
>>>       
>> later
>>     
>>> standardization) to allow a second application server to take over for
>>>       
>> a
>>     
>>> first application serer.
>>>
>>> 2. Put a cookie in the mediactrl PDU to identify the session.  So long
>>>       
>> as
>>     
>>> the control channel is secure (so the cookie doesn't leak out) and we
>>>       
>> go on
>>     
>>> passed from AS to AS, we probably will get through SECDIR review.  Up
>>>       
>> to you
>>     
>>> 4. Do the MGCP thing and let any yahoo take over the MS.  Well, extend
>>>       
>> the
>>     
>>> concept to do it securely, etc.  Right now I think this would fall
>>>       
>> into
>>     
>>> category 1, above.
>>>
>>> Thoughts?
>>>
>>>