The Secure Real-time Transport Protocol (SRTP)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, avt mailing list <email@example.com>, avt chair <firstname.lastname@example.org> Subject: Protocol Action: 'The Secure Real-time Transport Protocol' to Proposed Standard The IESG has approved the following document: - 'The Secure Real-time Transport Protocol ' <draft-ietf-avt-srtp-10.txt> as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-10.txt
Technical Summary This specification defines a profile for the Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) called the Secure Real-time Transport Protocol (SRTP). The security goals for SRTP are to ensure: * the confidentiality of the RTP and RTCP payloads, and * the integrity of the entire RTP and RTCP packets, together with protection against replayed packets. These security services are optional and independent from each other, except that SRTCP integrity protection is mandatory (malicious or erroneous alteration of RTCP messages could disrupt the processing of the RTP stream). Other, functional, goals for the protocol are: * a framework that permits upgrading with new cryptographic transforms, * low bandwidth cost, i.e., a framework preserving RTP header compression efficiency, The provision of integrity is strongly recommended for most applications of SRTP. The mandatory to implement transform for this profile is AES counter mode, and there are risks associated with not using cryptographic integrity with it (see Section 9.5). Working Group Summary The initial drafts had a default in which integrity services were not the norm and in which SRTCP did not have mandatory integrity protection. There was a lengthy security review to ensure that the authentication tag is recommended to most RTP recommendations. Protocol Quality The specification was reviewed for the IESG by Eric Rescorla and Allison Mankin. Implementations that tested the specification were discussed by the working group. RFC Editor Notes: Add a reference to RFC 1750 to the end of paragraph 1 of Section 1.1. Section 3.2.3 - Old: If no valid context can be found for a packet corresponding to a certain context identifier, that packet MUST be discarded from further processing. New: If no valid context can be found for a packet corresponding to a certain context identifier, that packet MUST be discarded.