|
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 at jmarkowitz.com From:
speechsc-bounces at ietf.org [mailto:speechsc-bounces at ietf.org] On Behalf Of Roni Even 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 at voxeo.com] 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 at ietf.org [mailto:rai-bounces at ietf.org] On
Behalf Of Dan York 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, -----Original Message-----
-- Dan York, Director of
Conversations Voxeo Corporation http://www.voxeo.com dyork at voxeo.com Phone:
+1-407-455-5859 Skype:
danyork
-- Dan York, Director of
Conversations Voxeo Corporation http://www.voxeo.com dyork at voxeo.com Phone:
+1-407-455-5859 Skype:
danyork |