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 90F0E3A67E2; Tue, 14 Jul 2009 13:27:14 -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 db3gDZjUuEQ9; Tue, 14 Jul 2009 13:27:13 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 6A7BF3A67D3; Tue, 14 Jul 2009 13:27:12 -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 49415385; Tue, 14 Jul 2009 20:16:18 +0000 Message-Id: <53ADC9B8-F9D2-4B27-A6D8-96B507911343@voxeo.com> From: Dan York To: Roni Even In-Reply-To: <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-146-859920856 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Jul 2009 16:16:16 -0400 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.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 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 20:27:14 -0000 --Apple-Mail-146-859920856 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 --Apple-Mail-146-859920856 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 h= ttp://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.c= om]
Sent: Thursday, July = 09, 2009 11:28 PM
To: Roni = Even
Cc: Saravanan Shanmugham; = Daniel Burnett; speechsc@ietf.org;
<= blockquote type=3D"cite">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/mail= man/listinfo/rai

-- 
Dan York, = Director of Conversations
Voxeo = Corporation   http://www.voxeo.com  dyork@voxeo.com
Phone: +1-407-455-5859    Skype: = danyork  









= --Apple-Mail-146-859920856--