Subject: [MEDIACTRL] Feedback on draft-ietf-mediactrl-requirements-02.txt (mostly related to security)

From: Dan York <[email-masked]>
Date: Thu, 20 Dec 2007 14:30:14 -0500

A couple of comments on the new requirements doc:

http://www.ietf.org/internet-drafts/draft-ietf-mediactrl- 
requirements-02.txt

(diff at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http:// 
tools.ietf.org/id/draft-ietf-mediactrl-requirements-02.txt )

1. In REQ-MCP-04:

    REQ-MCP-04 -  Media types supported in the context of the
       applications shall include audio, tones, text and video.  Tones
       media include in band audio or RFC 4733 payload.

how are you defining "text"?  It seemed to me in the IETF 70 meeting  
there was discussion about "real-time" text. Is that this?  Is this  
IM text?

2. In the same requirement, I find myself wondering about carrying  
"dataconferencing".  Frequently in a multi-modal conferencing  
environment there is the desire to share "web sessions" or "desktop  
sessions". For instance, a PowerPoint presentation.  Is that type of  
media covered here? (Perhaps as "video"?)

3. In the new REQ-MCP-11 it states "Since the solution need to" but  
should be "needs". (At least where I learned English.)

4. Personally, and maybe this is just a difference in style, I'm  
still not terribly thrilled about the security section 5 just  
basically saying that "we'll defer to the other protocols":

    The protocols that will meet the requirements described in this
    document will extend existing standards-track IETF protocols whose
    security properties are well understood.  Required security
    properties will be based on the available security tools.

I don't necessarily agree that the "security properties are well  
understood" for other IETF protocols.  I would suggest that we  
explicitly cover at least authentication and transport protection  
here so that anyone using a resulting protocol as a guide for  
implementation would see the security aspects directly in the protocol.

I would suggest expanding the existing REQ-MCP-11 into multiple  
requirements along the lines of:

   REQ-MCP-XX - The MS control protocol shall include an  
authentication component to ensure that only an authorized AS can  
communicate with the MS and vice versa.

(i.e. ensure that only the correct AS' and MS' are talking to each  
other, not allow unauthorized connections, etc.)

   REQ-MCP-XX - The MS control protocol shall use some form of  
transport protection to ensure the confidentiality and integrity of  
the stream between the AS and MS.

(i.e. prevent eavesdropping, modification of content, injection of  
other content, etc.)

   REQ-MCP-XX - Since the solution needs to support multiple AS  
controlling one MS, the MS control protocol requires mechanisms to  
protect the MS resources used by one AS from another AS.

(i.e. the multiple AS issue discussed at IETF 70 and included in this  
new draft)

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

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

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 20 Dec 2007 15:12:32 -0800

I would offer that Dan's suggestions for refining REQ-MCP-11 is an
excellent way to capture what we mean, as well as make the security
considerations' section actually say something.

Please +1 or complain quickly.

See below.

Thanks. 

________________________________

From: Dan York [mailto:[email-masked]] 
Sent: Thursday, December 20, 2007 2:30 PM
To: [email-masked]
Subject: [MEDIACTRL] Feedback on
draft-ietf-mediactrl-requirements-02.txt(mostly related to security)

[snip]

  REQ-MCP-XX - The MS control protocol shall include an authentication
component to ensure that only an authorized AS can communicate with the
MS and vice versa.

  REQ-MCP-XX - The MS control protocol shall use some form of transport
protection to ensure the confidentiality and integrity of the stream
between the AS and MS. 

(i.e. prevent eavesdropping, modification of content, injection of other
content, etc.)

[snip]

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: Thu, 20 Dec 2007 16:36:36 -0800

+1 if we clarify that the last requirement below does not prevent AS or
MS failover.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: December 20, 2007 3:13 PM
To: [email-masked]
Subject: [MEDIACTRL] Call for Consensus: Security Requirements

See below.

Thanks. 

[snip]

new draft) [snip]

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: Dan York <[email-masked]>
Date: Thu, 20 Dec 2007 20:12:46 -0500

> +1 if we clarify that the last requirement below does not prevent  

Fine by me. I was just throwing these out as suggestions and assumed  
that others would have refinements to what I wrote.  I also don't  
know that these capture all the security requirements, but it seemed  
a good start.

Regards,
Dan

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 21 Dec 2007 11:50:53 -0000

[Chris Boulton] +1

One clarification:

' REQ-MCP-XX - The MS control protocol shall use some form of transport
protection to ensure the confidentiality and integrity of the stream
between the AS and MS.'

Do we mean 'shall' or did we mean 'will allow the use of some'.  The
reason I ask is that it impacts the Control Framework.

Chris.

See below.

Thanks. 

[snip]

---

From: Dan York <[email-masked]>
Date: Fri, 21 Dec 2007 09:06:51 -0500

> reason I ask is that it impacts the Control Framework.

When I wrote that, my thought was that the MS control protocol should  
use some form of transport security such as TLS encryption or perhaps  
IPSec encryption.  Some mechanism that makes it so that the control  
signaling cannot be intercepted and read by a third party  
(eavesdropping, effectively) nor can it be modified in transit (or  
have new commands injected into the existing stream).  Looking for  
some way to protect against a Man-In-The-Middle who might either  
intercept or modify the protocol stream.  To my mind, probably the  
most likely solution is some form of encryption, but there may also  
be other solutions out there that others have.  I did not get more  
specific than "transport protection" because I've worked with  
requirements documents enough to value NOT getting into specifying  
implementation choices in requirements docs.

In answer to your 'shall' versus 'will allow the use of some', the  
latter case ('will...') is really a variant of "should", isn't it?  
i.e. transport encryption is not mandatory but is allowed.

Personally, I think this kind of communication between the AS and MS  
is potentially far too sensitive to NOT have transport protection, so  
my personal position would be "SHALL".   I think it should be  
mandatory.  If not, you just raise the number of ways that an  
attacker can attack these systems.  I am, of course, open to being  
convinced as to why securing the protocol in transit is not  
important. :-)

My 2 cents,
Dan

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 21 Dec 2007 14:57:34 -0000

In answer to your 'shall' versus 'will allow the use of some', the
latter case ('will...') is really a variant of "should", isn't it? i.e.
transport encryption is not mandatory but is allowed.

[Chris Boulton] Yes - this is the crux of my question.  The current
version of the Control Framework allows for TCP and TLS/TCP.

Personally, I think this kind of communication between the AS and MS is
potentially far too sensitive to NOT have transport protection, so my
personal position would be "SHALL".   I think it should be mandatory.
If not, you just raise the number of ways that an attacker can attack
these systems.  I am, of course, open to being convinced as to why
securing the protocol in transit is not important. :-)

[Chris Boulton] I totally agree with the security aspects.  I am
currently on the fence about making something like TLS the default to
implement.  This is probably historical in that currently media Servers
use SIP INFO - and they not by default encrypted + the majority of
today's deployments are in a 'trusted' environment and are not
encrypted.

So - in the Control Framework today we say use TCP and if you want
security - go use TLS.  I was happy with that but now I am starting to
doubt.

I am interested in the thoughts of the other MS vendors out there.  The
last thing we want to do is impose something that 'hurts' take-up by
enforcing something that is not always used.

Chris.

My 2 cents,

Dan

--

---

From: "Steve Buko" <[email-masked]>
Date: Fri, 21 Dec 2007 10:10:36 -0500

As you say, the majority of today's deployments are in a "trusted"
environment and are not encrypted.

My preference would be to use TCP as the default and if you want
security go with TLS.  

Enforcing TLS as the default is too restrictive IMO.

Steve

From: Chris Boulton [mailto:[email-masked]] 
Sent: Friday, December 21, 2007 9:58 AM
To: Dan York
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

Chris.

My 2 cents,

Dan

--

---

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 21 Dec 2007 15:14:52 +0000

Yes, I agree. We need to provide TLS for the non-trusted scenarios, but allow bare TCP/SCTP for others.

Scott

________________________________
From: Steve Buko [mailto:[email-masked]]
Sent: Friday, December 21, 2007 16:11
To: Chris Boulton; Dan York
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

As you say, the majority of today's deployments are in a "trusted" environment and are not encrypted.

My preference would be to use TCP as the default and if you want security go with TLS.
Enforcing TLS as the default is too restrictive IMO.

Steve

In answer to your 'shall' versus 'will allow the use of some', the latter case ('will...') is really a variant of "should", isn't it? i.e. transport encryption is not mandatory but is allowed.

[Chris Boulton] Yes - this is the crux of my question.  The current version of the Control Framework allows for TCP and TLS/TCP.

Personally, I think this kind of communication between the AS and MS is potentially far too sensitive to NOT have transport protection, so my personal position would be "SHALL".   I think it should be mandatory.  If not, you just raise the number of ways that an attacker can attack these systems.  I am, of course, open to being convinced as to why securing the protocol in transit is not important. :-)

[Chris Boulton] I totally agree with the security aspects.  I am currently on the fence about making something like TLS the default to implement.  This is probably historical in that currently media Servers use SIP INFO - and they not by default encrypted + the majority of today's deployments are in a 'trusted' environment and are not encrypted.

So - in the Control Framework today we say use TCP and if you want security - go use TLS.  I was happy with that but now I am starting to doubt.

I am interested in the thoughts of the other MS vendors out there.  The last thing we want to do is impose something that 'hurts' take-up by enforcing something that is not always used.

Chris.

My 2 cents,
Dan

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

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 21 Dec 2007 22:44:50 +0200

Chris,
The current language is not normative (non capital). I did not think
that we had to go to extended security requirements since anyhow they
are driven by the Security area. The focus I had was on the multiple AS
controlling one MS resources which should be in the protocol.

>From BFCP experience the AS to MS connection SHALL use TLS.

Roni

> Sent: Friday, December 21, 2007 1:51 PM
> To: Eric Burger; [email-masked]
transport
> (i.e. prevent eavesdropping, modification of content, injection of
other

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 21 Dec 2007 22:53:28 +0200

Chris,

Look at BFCP RFC 4582. It mandates the support of TLS but still TCP may
be used. I think such text covers your deployment question.

BTW: the is a use TLS error code.

Roni

From: Chris Boulton [mailto:[email-masked]] 
Sent: Friday, December 21, 2007 4:58 PM
To: Dan York
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Call for Consensus: Security Requirements

Chris.

My 2 cents,

Dan

--

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 21 Dec 2007 23:06:17 +0200

Dan,

Thanks

On the security I will change based on the consensus

As for the rest see Inline

Roni

From: Dan York [mailto:[email-masked]] 
Sent: Thursday, December 20, 2007 9:30 PM
To: [email-masked]
Subject: [MEDIACTRL] Feedback on draft-ietf-mediactrl-requirements-02.txt(mostly related to security)

http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-requirements-02.txt

(diff at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-mediactrl-requirements-02.txt )

1. In REQ-MCP-04:

how are you defining "text"?  It seemed to me in the IETF 70 meeting there was discussion about "real-time" text. Is that this?  Is this IM text?

[RE:] In IETF 70 it was for IVR. As for conferencing the meaning was IM text but it should cover also real-time text for people with disabilities. I prefer to leave as is. If there is a feeling to change II can add a sentence that text should cover real-time text and chat.

2. In the same requirement, I find myself wondering about carrying "dataconferencing".  Frequently in a multi-modal conferencing environment there is the desire to share "web sessions" or "desktop sessions". For instance, a PowerPoint presentation.  Is that type of media covered here? (Perhaps as "video"?)

[RE:] I think it will be a problem since I am not aware that we can point at a data conferencing application standard (except T.120). As for doing presentation over video this is a good point, but I think that in the AS to MS it is covered by defining the video layout and switching policy and the support for BFCP.

3. In the new REQ-MCP-11 it states "Since the solution need to" but should be "needs". (At least where I learned English.)

[RE:] OK

4. Personally, and maybe this is just a difference in style, I'm still not terribly thrilled about the security section 5 just basically saying that "we'll defer to the other protocols":

I don't necessarily agree that the "security properties are well understood" for other IETF protocols.  I would suggest that we explicitly cover at least authentication and transport protection here so that anyone using a resulting protocol as a guide for implementation would see the security aspects directly in the protocol.

I would suggest expanding the existing REQ-MCP-11 into multiple requirements along the lines of:

  REQ-MCP-XX - The MS control protocol shall include an authentication component to ensure that only an authorized AS can communicate with the MS and vice versa.

(i.e. ensure that only the correct AS' and MS' are talking to each other, not allow unauthorized connections, etc.)

  REQ-MCP-XX - The MS control protocol shall use some form of transport protection to ensure the confidentiality and integrity of the stream between the AS and MS. 

(i.e. prevent eavesdropping, modification of content, injection of other content, etc.)

  REQ-MCP-XX - Since the solution needs to support multiple AS controlling one MS, the MS control protocol requires mechanisms to protect the MS resources used by one AS from another AS.

(i.e. the multiple AS issue discussed at IETF 70 and included in this new draft)

Regards,

Dan

--

---

From: Eric Burger <[email-masked]>
Date: Sun, 23 Dec 2007 09:27:01 -0500

<Chair hat on>

As Roni pointed out in a different message:
On 12/21/07 3:53 PM, "Even, Roni" <[email-masked]> wrote:

> Chris,
> Look at BFCP RFC 4582. It mandates the support of TLS but still TCP may be
> used. I think such text covers your deployment question.
Roni

Here is the deal: this is the INTERNET Engineering Task Force, not the
PRIVATE, HAPPENS TO RUN OVER IP work group.

For a protocol to be an Internet protocol, it must run on the Internet.
That means Internet scale, Internet security, Internet privacy, and Internet
operations.

What that means for us in the work group is the limited deployment scenario
described below is just short of out-of-scope. We say ³just short² because
we also know it is the most prevalent use case today.  If we do not think we
will ever deploy on the Internet, then as chair I would have to say the work
of the work group is finished. If you think this is the case, ETSI/TISPAN or
ITU would be a better venue for work on this protocol.

Since I pushed for the charter, I believe mediactrl will be an Internet
protocol. That means we have to build it for Internet deployment. It means
the non-trusted scenario is the default scenario. The trusted scenario is a
special case. Moreover, it means that servers MUST (2192 language here)
support the default scenario. Otherwise, they are not supporting an Internet
protocol, and as such would not be supporting mediactrl.

What does that mean for the particular question of TLS versus TCP? It means
that for requirements, servers MUST support authentication and security such
as found with TLS. For implementation, servers MUST support (for example)
TLS. In IETF parlance, we call this ³minimum mandatory to implement.²
Moreover, even if a server gets deployed in a trusted network, IT STILL MUST
IMPLMENET TLS. Remember, the client can always CHOSE to not use TLS.
However, the server still MUST offer it. Start to see a pattern here with
the ³MUST²s?

Likewise, since we live in the real world, we also say servers MAY support
TCP (for example) for situations where the server and client are deployed in
a secure, private network (note the inclusion of explanatory text). That
gives server manufacturers a clue they might also include TCP support.
However, TLS (or whatever) MUST still be there.

On 12/21/07 10:14 AM, "McGlashan, Scott" <[email-masked]> wrote:

> As you say, the majority of today¹s deployments are in a ³trusted² environment
> and are not encrypted.
>  
> In answer to your 'shall' versus 'will allow the use of some', the latter case
> ('will...') is really a variant of "should", isn't it? i.e. transport
> encryption is not mandatory but is allowed.
> 
>  
> [Chris Boulton] Yes  this is the crux of my question.  The current version of
> the Control Framework allows for TCP and TLS/TCP.
>  
> 
> potentially far too sensitive to NOT have transport protection, so my personal
> position would be "SHALL".   I think it should be mandatory.  If not, you just
> raise the number of ways that an attacker can attack these systems.  I am, of
> course, open to being convinced as to why securing the protocol in transit is
> not important. :-)
> 
>  
> [Chris Boulton] I totally agree with the security aspects.  I am currently on
> the fence about making something like TLS the default to implement.  This is
> probably historical in that currently media Servers use SIP INFO  and they
> not by default encrypted + the majority of today¹s deployments are in a
> Œtrusted¹ environment and are not encrypted.
>  
> So  in the Control Framework today we say use TCP and if you want security 
> go use TLS.  I was happy with that but now I am starting to doubt.
>  
> I am interested in the thoughts of the other MS vendors out there.  The last
> thing we want to do is impose something that Œhurts¹ take-up by enforcing
> something that is not always used.
>  
> Chris.
>  
>  
> 
> My 2 cents,
> 
> Dan
> 
>