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 D1E063A683A for ; Wed, 15 Jul 2009 10:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 b-M8p5mgaD6e for ; Wed, 15 Jul 2009 10:30:27 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by core3.amsl.com (Postfix) with ESMTP id DDD273A6BF8 for ; Wed, 15 Jul 2009 10:30:25 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr7.mgt.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id n6FHTMcE013222 for ; Wed, 15 Jul 2009 13:29:24 -0400 Message-Id: <200907151729.n6FHTMcE013222@omr7.networksolutionsemail.com> Received: (qmail 25960 invoked by uid 78); 15 Jul 2009 17:29:21 -0000 Received: from unknown (HELO JMarkowitz) (judith@jmarkowitz.com@24.148.52.60) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 15 Jul 2009 17:29:21 -0000 From: "Judith Markowitz" To: "'Roni Even'" , "'Dan York'" Date: Wed, 15 Jul 2009 12:28:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CA0547.C0955730" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcoEx4wp7NhipJKURgG7lWCJ5mWaSgAAykQQACmXH9A= In-Reply-To: <4a5cfa64.0aa5660a.1918.ffff94d6@mx.google.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 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: Wed, 15 Jul 2009 17:30:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002C_01CA0547.C0955730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I want to support the position of recommending but not mandating. The approach used needs to comply with the policies and procedures of an organization. It could very well be that those policies and procedures are far more stringent than anything that would be mandated by MRCP V2. So, if a particular approach or technology is mandated the use of MRCP may be rejected because the security is not adequate or proper. Judith Markowitz J. Markowitz, Consultants 5801 N. Sheridan Rd, #19A Chicago, IL 60660 773-769-9243 judith@jmarkowitz.com _____ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, July 14, 2009 4:36 PM To: 'Dan York' Cc: speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org; 'Roni Even' Subject: 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 ------=_NextPart_000_002C_01CA0547.C0955730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I want to support the position of recommending but not mandating. The approach used needs to comply with = the policies and procedures of an organization. =

It could very well be that those = policies and procedures are far more stringent than anything that would be = mandated by MRCP V2. So, if a particular approach

or  technology is mandated the = use of MRCP may be rejected because the security is not adequate or proper. =

 

Judith = Markowitz

 

J. Markowitz, = Consultants

5801 N. Sheridan Rd, = #19A

Chicago, IL 60660

773-769-9243

judith@jmarkowitz.com

 

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Roni Even
Sent: Tuesday, July 14, = 2009 4:36 PM
To: 'Dan York'
Cc: speechsc@ietf.org; = 'Saravanan Shanmugham'; rai@ietf.org; 'Roni Even'
Subject: 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

 <= /o:p>

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,<= /font>

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,

=

  

------=

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,<= /p>

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-----

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

To: Roni = Even

Cc: Saravanan Shanmugham; Daniel = Burnett; speechsc@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

not-mandatory-02=

for discussion on media = security.



_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/m= ailman/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<= font color=3Dblack>

Facebook: http://www.facebook.com/voxeo<= /span>

 =



 =

 =

 =

 =

 

 

 

-- =

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:

 

 

 

 

 

 

 

 

------=_NextPart_000_002C_01CA0547.C0955730--