Re: [Speechsc] [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