Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

Dan,

I prefer the text that recommends SRTP (It is a SHOULD and not a MUST). The
text we currently have is based on the security reviews we got for RTP
payload specifications, and as you can see it addresses the issue of why not
to mandate SRTP.

Roni

From: Dan York [mailto:dyork@voxeo.com] 
Sent: Wednesday, July 15, 2009 12:11 AM
To: Roni Even
Cc: 'Roni Even'; 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan
Shanmugham'; rai@ietf.org
Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

Roni,

So as the RAI reviewer, are you okay with the text I suggested:

------

12.3. Media session protection 
Sensitive data is also carried on media sessions terminating on MRCPv2
servers (the other end of a media channel may or may not be on the MRCPv2
client). This data includes the user's spoken utterances    and the output
of text-to-speech operations. MRCPv2 servers MUST support a security
mechanism for protection of audio media sessions. MRCPv2 clients that
originate or consume audio similarly MUST support a security mechanism for
protection of the audio. 

------

Or would you prefer this text that includes the recommendation of SRTP?
(Which I noticed you did in the RTP payloads spec - and it makes sense to me
to provide some basic guidance.):

------

12.3. Media session protection 
Sensitive data is also carried on media sessions terminating on MRCPv2
servers (the other end of a media channel may or may not be on the MRCPv2
client). This data includes the user's spoken utterances    and the output
of text-to-speech operations. MRCPv2 servers MUST support a security
mechanism for protection of audio media sessions. MRCPv2 clients that
originate or consume audio similarly MUST support a security mechanism for
protection of the audio. If appropriate, usage of the Secure Real-time
Transport Protocol (SRTP) [RFC3711] is recommended.

------

Regards,

Dan

Regards,

Dan

On Jul 14, 2009, at 4:55 PM, Roni Even wrote:

Dan,

This is the general idea. The major reason is that there are various ways to
protect the data and if you are not mandating one for interoperability then
it can be more general

For example we have the following text when discussing security in the RTP
payloads specifications.

RTP packets using the payload format defined in this specification

   are subject to the security considerations discussed in the RTP

   specification [RFC3550] and any appropriate RTP profile.  The main

   security considerations for the RTP packet carrying the RTP payload

   format defined within this memo are confidentiality, integrity, and

   source authenticity.  Confidentiality is achieved by encryption of

   the RTP payload.  Integrity of the RTP packets is achieved through a

   suitable cryptographic integrity protection mechanism.  Such a

   cryptographic system may also allow the authentication of the source

   of the payload.  A suitable security mechanism for this RTP payload

   format should provide confidentiality, integrity protection, and at

   least source authentication capable of determining if an RTP packet

   is from a member of the RTP session.

   Note that the appropriate mechanism to provide security to RTP and

   payloads following this memo may vary.  It is dependent on the

   application, the transport, and the signaling protocol employed.

   Therefore, a single mechanism is not sufficient, although if

   suitable, usage of the Secure Real-time Transport Protocol (SRTP)

   [RFC3711] recommended.  Other mechanisms that may be used are IPsec

   [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP);

   other alternatives may exist.

Roni Even

From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan
York
Sent: Tuesday, July 14, 2009 11:16 PM
To: Roni Even
Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham';
rai@ietf.org
Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

Roni,

The current text at
http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 is:

------
12.3. Media session protection  
Sensitive data is also carried on media sessions terminating on MRCPv2
servers (the other end of a media channel may or may not be on the MRCPv2
client). This data includes the user's spoken utterances and the output of
text-to-speech operations. MRCPv2 servers MUST support SRTP for protection
of audio media sessions. MRCPv2 clients that originate or consume audio
similarly MUST support SRTP. Alternative media channel protection MAY be
used if desired (e.g. IPSEC).

------

Based on your comments and the srtp-not-mandatory draft (which was just
revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03
), my understanding would be that you are advocating something more like
this:

------

12.3. Media session protection 
Sensitive data is also carried on media sessions terminating on MRCPv2
servers (the other end of a media channel may or may not be on the MRCPv2
client). This data includes the user's spoken utterances    and the output
of text-to-speech operations. MRCPv2 servers MUST support a security
mechanism for protection of audio media sessions. MRCPv2 clients that
originate or consume audio similarly MUST support a security mechanism for
protection of the audio. 

------

Is that an accurate summary of your feedback?  Would that text be
acceptable?

Regards,

Dan

On Jul 9, 2009, at 4:56 PM, Roni Even wrote:

Eric,
My comment is that in this case in AVT we say that you do not need to
mandate SRTP but mandate a security mechanism that can be  not only SRTP but
in a different layer like ipsec. This is why I gave a reference to the
srtp-not-mandatory draft

Roni

-----Original Message-----

From: Eric Burger [mailto:eburger@standardstrack.com]

Sent: Thursday, July 09, 2009 11:28 PM

To: Roni Even

Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org;

rai@ietf.org

Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19

The reality is that NO ONE has implemented any security to date. The

GENART reviewer raised the same issue, and so far the work group has

the same response: MRCPv2 (the speechsc work group) is not planning on

figuring out which of the seven key exchange mechanisms to use in

SIP.  We are counting on the community publishing something, and

people using it.  After all, we are the "using SIP for media resource

control" work group, not the "media resource control work group using

something like SIP for control."

Does this work for you?

On Jul 7, 2009, at 3:40 PM, Roni Even wrote:

[snip]

18.   In section 12.3 the suggestion is to use SRTP as the mandatory

interoperability mode. If the reason for mandating SRTP is for a

common mode you should also decide on a key exchange mechanism. I

suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp-

not-mandatory-02

for discussion on media security.

_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

-- 

Dan York, Director of Conversations

Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com

Phone: +1-407-455-5859    Skype: danyork  

Join the Voxeo conversation:

Blogs: http://blogs.voxeo.com

Twitter: http://twitter.com/voxeo  http://twitter.com/danyork

Facebook: http://www.facebook.com/voxeo

-- 

Dan York, Director of Conversations

Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com

Phone: +1-407-455-5859    Skype: danyork  

Join the Voxeo conversation:

Blogs: http://blogs.voxeo.com

Twitter: http://twitter.com/voxeo  http://twitter.com/danyork

Facebook: http://www.facebook.com/voxeo