Technical Summary
This document define SRTP procedures for enabling end to end media
confidentiality and integrity for end-points in a Multimedia conferences.
It does so by defining 2 types of SRTP transforms - outer and inner.
The inner transform is responsible for ensuring end-to-end integrity
and encryption. The outer transform covers integrity and encryption
hop-by-hop (between endpoints and the media distributor or between
the media distributors).
Working Group Summary
This document has been discussed and reviewed several times by the
WG. There were few individuals with concerns regarding the
following areas
1. Allow Media distributor (MD) to modify the SSRC field
in the RTP header. However they weren't able to propose
solutions that can mitigate the SSRC splicing attack
identified by the WG. Also to note, the WG had previously
reached consensus on non-modifiability of the SSRC by the
media distributor. However, the discussion was re-opened to
help the concerned individual to put forward the proposals.
But as aforementioned, there was no proposal submitted that
satisfactorily addressed the splicing attack. Hence the
WG decided to go forward with previously reached consensus to
not allow MD to modify the SSRC.
2. Mechanisms to carry the end to end scoped payload header information:
Originally the proposal was to carry such information as an
RTP header extension. However, there was a proposal to
carry similar information as the payload header. The authors of the
document made accommodations to work out a solution that addressed
the concern. This involved moving the OHB from header extension to
payload header as part of the endpoint procedures.
Additionally there were complaints about complexity and
bits on the wire. However, no one brought alternative
proposals to the WG that met the security objectives.
The chairs called for consensus - in-room and on-list -, there was
support to go with the procedures defined in the current version
of the specification. Even though there are few individuals who aren't
totally happy, the WG had consensus on the proposals.
Also there were discussions on solution approaches for dealing
with the repair packets. Two possible solutions were discussed. One was
related to applying the hop-by-hop transform for the repair packet on
the single encrypted packet vs double encrypted packet. The former
implying a split in SRTP transform context states (E2E, RTX, HBH) and
the latter implying a simple canonical way of doing classic SRTP
(But just with a new transform called double). Hence the latter approach
was chosen given its simplicity of implementing on plethora of end-points
versus acceptable extra processing needed on relatively lower number of MD implementations.
Some objections were raised in the working group, and re-raised during the first IETF LC,
proposing that the encryption applied by PERC should be split so that in the WebRTC case,
E2E keys could be supplied by someone other than the browser. It became clear in both
WG discussions and post-LC discussions involving the ADs that this would be counter to
the WebRTC security model, which is required in the PERC charter. So any work to address
these concerns would be future work, and not blocking on the current documents.
Document Quality
libsrtp, a widely used SRTP library in commercial and open source
SIP and Webrtc products, has a branch with the implementation
for double encryption procedures as defined in this specification.
This document did not require expert review of the types noted.
Personnel
The document shepherd is Suhas Nandakumar;
the responsible Area Director is Alexey Melnikov.