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
------
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).
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?
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
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.
Dan York, Director of Conversations
Phone: +1-407-455-5859 Skype: danyork
Join the Voxeo conversation: