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