Subject: Re: [MEDIACTRL] Multiple AS Security Issues

From: "Eric Burger" <[email-masked]>
Date: Tue, 4 Dec 2007 21:40:06 -0800

As written today, a new control channel MUST NOT be allowed to manipulate or access existing SIP dialogs.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

----- Original Message -----
From: Adnan Saleem <[email-masked]>
To: Lorenzo Miniero <[email-masked]>; Eric Burger
Cc: [email-masked] <[email-masked]>
Sent: Tue Dec 04 21:33:58 2007
Subject: RE: [MEDIACTRL] Multiple AS Security Issues

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

--
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]>:

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

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

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

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: "Adnan Saleem" <[email-masked]>
Date: Tue, 4 Dec 2007 21:53:44 -0800

I guess I don't see how forcing the use of the same control channel
would
provide better security ? When a security association is established
between
AS1 and MS, and then AS2 takes over, would all the security credentials
need to be 'moved' to AS2 to be able to continue using the same control
channel ? If a new channel is established by AS2 a new set of security
credentials can be established, and the only reason AS2 would know
anything about existing SIP dialogs is because AS1 was replicating
these to AS2 (probably over a secure channel as well) for purpose 
of providing redundancy.

Adnan

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

As written today, a new control channel MUST NOT be allowed to
manipulate or access existing SIP dialogs.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need
lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what
lemonade is.

----- Original Message -----
From: Adnan Saleem <[email-masked]>
To: Lorenzo Miniero <[email-masked]>; Eric Burger
Cc: [email-masked] <[email-masked]>
Sent: Tue Dec 04 21:33:58 2007
Subject: RE: [MEDIACTRL] Multiple AS Security Issues

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

Lorenzo

in the
accidentally
application
need to
of load
and
later
a
as
go on

to you
the
into
contain
affiliated
and/or
individual or
and have
email and

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: Eric Burger <[email-masked]>
Date: Tue, 04 Dec 2007 22:39:37 -0800

Not where I was going: it is IMPOSSIBLE to use the same control channel if
we are using a secure, end-to-end (i.e., TLS) channel.  Certificates should
not match, unless we mandate IP Address takeover.