Subject: RE: [Speechsc] Default support for TLS?

From: "Burger, Eric" <[email-masked]>
Date: Sat, 18 Mar 2006 16:24:40 -0500

(Not to Jeff, but to the list)

Bad security in other protocols does not mean we need to make the same mistakes.  Sarvi is correct in his guess that we have the microscope up our rectum over speaker identification.

Usually, we see "server MUST implement TLS" as the requirement.  That leaves it up to the client if they wish to use TLS.  The client knows it is always there.  However, one would be correct if one asserted that we ARE being held to a higher standard.  That is because we are.  This is why we have the stronger language imposing security guidelines on the client.

 -----Original Message-----
From: 	Shanmugham, Saravanan [mailto:[email-masked]]
Sent:	Fri Mar 17 00:41:49 2006
To:	Jeff Haynie; IETF SPEECHSC; Dan Burnett
Subject:	RE: [Speechsc] Default support for TLS?

Security getting a priority seems IETF wide. I cannot speak for the
other protocols, but if I understand right, we seemed to have got
special attention as we are dealing with Speaker Identification and
Verification, which is biometrics.
 
In section we do secure all 3 levels of protocols, SIP, MRCP control
channel and media. Though the control channel and media is the important
ones here.
 
Requiring that all clients and servers support TLS and SRTP as a MUST is
a requirement for compliance. I don't believe the spec forces you to use
it though. Which is why it allows regular SIP, RTP and TCP as well for
control and media. 
 
So is there an issue I am missing here.
 
Sarvi

________________________________

	From: Jeff Haynie [mailto:[email-masked]] 
	Sent: Thursday, March 16, 2006 9:23 PM
	To: Shanmugham, Saravanan; IETF SPEECHSC; Dan Burnett
	Subject: RE: [Speechsc] Default support for TLS?

	OK, I agree security is import in general terms....  I'm
interested why other drafts/RFCs don't take this "security on by
default" approach:

	1.	SIP (with the exception of Digest, but not transport
level) 
	2.	RTP 
	3.	HTTP 
	4.	BCP 
	5.	SIMPLE 
	6.	MSRP 
	7.	SIPPING-CONFIG-FRAMEWORK 

	I also surveyed the last 4-5 I-D Action drafts and none seemed
had this level of MUST in their Security Considerations.
SIPPING-CONFIG-FRAMEWORK [1] has a more reasonably detailed Security
Consideration section which details conditions when security is
appropriate. However, it still only requires HTTP or HTTPS and is SHOULD
for SIP Authentication for profile delivery servers.

	Also, if you don't use secure RTP and SIPS for the endpoints,
having TLS for MRCPv2 most likely is just half-baked since I can just
listen in/redirect the endpoint stream in the middle and get the entire
conversation.  

	So, I'm not opposed to security at all - I'm really more
interested in (a) why is it on by default when you're only partially
addressing the issue and thus creating a security vulnerability and (b)
questioning a more thorough look at what Security Considerations might
be needed if we make it a MUST?

	Additionally, we're only securing the control channel. If we're
going to get into security details, what about security implications of
the data contained within the SIP/SDP message body itself - is that also
required to be encrypted?  Could a replay or man in the middle attack be
created with session data in the payload as well even if the transport
pipe is secured?   

	Jeff

	[1]
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
08.txt

________________________________

	From: Shanmugham, Saravanan [mailto:[email-masked]] 
	Sent: Thursday, March 16, 2006 7:07 PM
	To: Jeff Haynie; IETF SPEECHSC
	Subject: RE: [Speechsc] Default support for TLS?

	What this means is that both MRCPv2 clients and servers MUST
support TLS for securing the control channel.

	It also means that the MRCPv2 client should always default to
using TLS. 

	This does not mean that the client cannot use a plain TCP pipe
to talk to the MRCPv2 server 

	"All servers MUST support TLS, SHOULD support TCP without TLS,
and MAY support SCTP."

	So I agree we should design to be out of the box secure.
Security can be turned off on the client as needed.

	Sarvi 

________________________________

		From: Jeff Haynie [mailto:[email-masked]] 
		Sent: Thursday, March 16, 2006 11:34 AM
		To: IETF SPEECHSC
		Subject: RE: [Speechsc] Default support for TLS?

		I'd like to echo Jerry's concern where in plenty of
deployments TLS might be overkill or might be superceded by something
which handles security in a different manner like IPsec.  I could
certainly see plenty of use cases and deployments where a compliant
MRCPv2 client doesn't need TLS and shouldn't have to support it.

________________________________

		From: Carter, Jerry [mailto:[email-masked]] 
		Sent: Thursday, March 16, 2006 2:13 PM
		To: IETF SPEECHSC
		Subject: [Speechsc] Default support for TLS?

		I've been trying to understand the origin of the
language in section 12.2:

		    To ensure control channel protection, MRCPv2 clients
		    and servers MUST support TLS and SHOULD utilize it
		    by default.  Alternative control channel protection
		    MAY be used if desired (e.g. IPSEC).

		I understand the need for TLS support as a technique for
addressing security concerns in many environments.  TLS is a good thing.
But, I do not understand why TLS defaults to 'ON'.  

		Looking back at the minutes from summer 2004 (e.g.
http://www1.ietf.org/mail-archive/web/speechsc/current/msg00888.html)
when TLS was added, I cannot find anyone arguing for this default value.
Looking at the emails between drafts 6 (where TLS was not the default)
and 7 (when TLS became the default), I can't find anyone arguing for
this change.  When did the SpeechSC group agree to this?

		I am concerned here because the majority of telephony
deployments, the MRCP server and client are running on the same trusted
network.  In many cases, the cpu & latency costs for performing an
unnecessary encryption step are desired.  For these buyers, using TLS by
default is a barrier for deployment.

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Corby Anderson <[email-masked]>
Date: Sun, 19 Mar 2006 09:02:14 -0800

It makes sense that things like speaker verification should be held to a 
higher standard security-wise than other recognition tasks, so I agree 
that including security is a "MUST."

But are we planning on claiming that securing the MRCP control channel 
is sufficient to secure a speaker identification system?  As Jeff 
pointed out in his 3/16 email, if we don't secure the RTP endpoints, 
then can't a snooper just pick up the audio itself?  If we're going to 
take the half-measure of securing the control channel but not the RTP 
stream (which might not really be such a bad idea -- security has to 
start somewhere, and it might not be feasible to secure everything all 
at once) then should we include some text in the spec along the lines of 
"while securing the MRCP control channel will prevent attackers from 
capturing MRCP control channel data, RTP and SIP information must be 
secured separately in order to prevent attackers from being able to 
capture that data.  Securing the RTP and SIP information is not 
addressed in MRCPv2."

That way, we would make it clear that simply securing the MRCP channel 
is not enough to prevent an attacker from compromising a speaker 
verification or recognition exchange.  If the microscope really is where 
you say it is (ouch!), then someone else is bound to point out this 
security problem.

Corby Anderson
Tellme Networks

Burger, Eric wrote:
> Bad security in other protocols does not mean we need to make the same 
> mistakes.  Sarvi is correct in his guess that we have the microscope 
> up our rectum over speaker identification.
>
> Usually, we see "server MUST implement TLS" as the requirement.  That 
> leaves it up to the client if they wish to use TLS.  The client knows 
> it is always there.  However, one would be correct if one asserted 
> that we ARE being held to a higher standard.  That is because we are.  
> This is why we have the stronger language imposing security guidelines 
> on the client.
>
> ------------------------------------------------------------------------
>

---

From: David R Oran <[email-masked]>
Date: Sun, 19 Mar 2006 12:13:31 -0500

On Mar 19, 2006, at 12:02 PM, Corby Anderson wrote:

> It makes sense that things like speaker verification should be held  
> to a higher standard security-wise than other recognition tasks, so  
> I agree that including security is a "MUST."
>
> But are we planning on claiming that securing the MRCP control  
> channel is sufficient to secure a speaker identification system?   
> As Jeff pointed out in his 3/16 email, if we don't secure the RTP  
> endpoints, then can't a snooper just pick up the audio itself?
Right. That's why SRTP is highly recommended as well.

> If we're going to take the half-measure of securing the control  
> channel but not the RTP stream (which might not really be such a  
> bad idea -- security has to start somewhere, and it might not be  
> feasible to secure everything all at once) then should we include  
> some text in the spec along the lines of "while securing the MRCP  
> control channel will prevent attackers from capturing MRCP control  
> channel data, RTP and SIP information must be secured separately in  
> order to prevent attackers from being able to capture that data.   
> Securing the RTP and SIP information is not addressed in MRCPv2."
>
> That way, we would make it clear that simply securing the MRCP  
> channel is not enough to prevent an attacker from compromising a  
> speaker verification or recognition exchange.  If the microscope  
> really is where you say it is (ouch!), then someone else is bound  
> to point out this security problem.
>
> Corby Anderson
> Tellme Networks
>
> Burger, Eric wrote:
>> Bad security in other protocols does not mean we need to make the  
>> same mistakes.  Sarvi is correct in his guess that we have the  
>> microscope up our rectum over speaker identification.
>>
>> Usually, we see "server MUST implement TLS" as the requirement.   
>> That leaves it up to the client if they wish to use TLS.  The  
>> client knows it is always there.  However, one would be correct if  
>> one asserted that we ARE being held to a higher standard.  That is  
>> because we are.  This is why we have the stronger language  
>> imposing security guidelines on the client.
>>
>> _______________________________________________ Speechsc mailing  
>> list [email-masked] https://www1.ietf.org/mailman/listinfo/ 
>> speechsc