draft-ietf-avt-srtp-not-mandatory-15.txt | draft-ietf-avt-srtp-not-mandatory-16.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational M. Westerlund | Intended status: Informational M. Westerlund | |||
Expires: July 20, 2014 Ericsson | Expires: July 20, 2014 Ericsson | |||
January 16, 2014 | January 16, 2014 | |||
Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | |||
Media Security Solution | Media Security Solution | |||
draft-ietf-avt-srtp-not-mandatory-15.txt | draft-ietf-avt-srtp-not-mandatory-16.txt | |||
Abstract | Abstract | |||
This memo discusses the problem of securing real-time multimedia | This memo discusses the problem of securing real-time multimedia | |||
sessions, and explains why the Real-time Transport Protocol (RTP), | sessions, and explains why the Real-time Transport Protocol (RTP), | |||
and the associated RTP Control Protocol (RTCP), do not mandate a | and the associated RTP Control Protocol (RTCP), do not mandate a | |||
single media security mechanism. This is relevant for designers and | single media security mechanism. This is relevant for designers and | |||
reviewers of future RTP extensions, to ensure that appropriate | reviewers of future RTP extensions, to ensure that appropriate | |||
security mechanisms are mandated, and that any such mechanisms are | security mechanisms are mandated, and that any such mechanisms are | |||
specified in a manner that conforms with the RTP architecture. | specified in a manner that conforms with the RTP architecture. | |||
skipping to change at page 5, line 51 | skipping to change at page 5, line 51 | |||
More importantly, though, the security requirements for the different | More importantly, though, the security requirements for the different | |||
usage scenarios vary widely, and an appropriate security mechanism in | usage scenarios vary widely, and an appropriate security mechanism in | |||
one scenario simply does not work for some other scenarios. | one scenario simply does not work for some other scenarios. | |||
For a framework protocol, it appears that the only sensible solution | For a framework protocol, it appears that the only sensible solution | |||
to the strong security requirement of [RFC3365] is to develop and use | to the strong security requirement of [RFC3365] is to develop and use | |||
building blocks for the basic security services of confidentiality, | building blocks for the basic security services of confidentiality, | |||
integrity protection, authorisation, authentication, and so on. When | integrity protection, authorisation, authentication, and so on. When | |||
new uses for the framework protocol arise, they need to be studied to | new uses for the framework protocol arise, they need to be studied to | |||
determine if the existing security building blocks can satisfy the | determine if the existing security building blocks can satisfy the | |||
requirements, or if new building blocks need to be developed. A | requirements, or if new building blocks need to be developed. | |||
mandatory to implement set of security building blocks can then be | ||||
specified for that usage scenario of the framework. | ||||
Therefore, when considering the strong and mandatory to implement | Therefore, when considering the strong and mandatory to implement | |||
security mechanism for a specific class of applications, one has to | security mechanism for a specific class of applications, one has to | |||
consider what security building blocks need to be supported. To | consider what security building blocks need to be integrated, or if | |||
maximize interoperability it is important that common media security | any new mechanisms need to be defined to address specific issues | |||
and key management mechanisms are defined for classes of application | relating to this new class of application. To maximize | |||
with similar requirements. The IETF needs to participate in this | interoperability it is important that common media security and key | |||
management mechanisms are defined for classes of application with | ||||
similar requirements. The IETF needs to participate in this | ||||
selection of security building blocks for each class of applications | selection of security building blocks for each class of applications | |||
that use the protocol framework and are expected to interoperate, in | that use the protocol framework and are expected to interoperate, in | |||
cases where the IETF has the appropriate knowledge of the class of | cases where the IETF has the appropriate knowledge of the class of | |||
applications. | applications. | |||
6. Securing the RTP Protocol Framework | 6. Securing the RTP Protocol Framework | |||
The IETF requires that protocols specify mandatory to implement (MTI) | The IETF requires that protocols specify mandatory to implement (MTI) | |||
strong security [RFC3365]. This applies to the specification of each | strong security [RFC3365]. This applies to the specification of each | |||
interoperable class of application that makes use of RTP. However, | interoperable class of application that makes use of RTP. However, | |||
End of changes. 3 change blocks. | ||||
8 lines changed or deleted | 8 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |