Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34293A6A3F; Tue, 14 Jul 2009 14:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkrYvp774Kpa; Tue, 14 Jul 2009 14:13:00 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id BE93A3A6B50; Tue, 14 Jul 2009 14:11:06 -0700 (PDT) Received: from [66.65.229.48] (account dyork HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 49416723; Tue, 14 Jul 2009 21:10:40 +0000 Message-Id: From: Dan York To: "Roni Even" In-Reply-To: <4a5cf0da.190c660a.3ec0.58fa@mx.google.com> Content-Type: multipart/alternative; boundary=Apple-Mail-147-863182515 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Jul 2009 17:10:38 -0400 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> <53ADC9B8-F9D2-4B27-A6D8-96B507911343@voxeo.com> <4a5cf0da.190c660a.3ec0.58fa@mx.google.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 15 Jul 2009 08:14:53 -0700 Cc: speechsc@ietf.org, 'Saravanan Shanmugham' , rai@ietf.org, 'Roni Even' Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:13:02 -0000 --Apple-Mail-147-863182515 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 --Apple-Mail-147-863182515 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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,
D= an

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

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
   cryptographic system may also allow the = authentication of the source
   of the = payload.  A suitable security mechanism for this RTP = payload
Roni = Even
 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
 
The current text = at  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).
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:
18. =   In section 12.3 the suggestion is to use SRTP as the = mandatory
common mode = you should also decide on a key exchange mechanism. = I
Phone: +1-407-455-5859    Skype: = danyork  
Join the Voxeo = conversation:




= --Apple-Mail-147-863182515--