Protocol Action: 'The Secure Real-time Transport Protocol' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved following document:

- 'The Secure Real-time Transport Protocol '
   <draft-ietf-avt-srtp-09.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.

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.



[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux