Subject: [AVTCORE] [Errata Held for Document Update] RFC3711 (3712)

From: RFC Errata System <[email-masked]>
Date: Sat, 15 Feb 2014 10:37:57 -0800 (PST)

The following errata report has been held for document update 
for RFC3711, "The Secure Real-time Transport Protocol (SRTP)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=3712

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Christian S Oien <[email-masked]>
Date Reported: 2013-08-27
Held by: Richard Barnes (IESG)

Section: 4.3.2

Original Text
-------------
Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index
 (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use
<label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the
SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting
key.

Corrected Text
--------------
Replace the SRTP index by the 48-bit quantity: 000...0 || 0 || SRTCP
index (i.e., excluding the E-bit, replacing it with a fixed 0-bit and
padding the result so that it becomes 48 bits wide to match the size
of the SRTP index). Since this quantity and the SRTP index are both
48 bits wide, the labels are all located in the same octet in the IV.
The labels for the derivations of the SRTCP keys are as follows:   
<label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the 
SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting 
key.

Notes
-----
Replacing with a 32-bit quantity means that the DIV operator will
yield a 32-bit quantity.  Following the specification of key_id for SRTCP
the <label> will have 32 bits to its right when XOR'ing with master_salt.

The majority of implementations, including libsrtp, invokes this XOR with the
<label> at the same position as for SRTP.  According to the specification
this should be done 16 bits to the right of this, when invoking for SRTCP.

--------------------------------------
RFC3711 (draft-ietf-avt-srtp-09)
--------------------------------------
Title               : The Secure Real-time Transport Protocol (SRTP)
Publication Date    : March 2004
Author(s)           : M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Richard Barnes <[email-masked]>
Date: Sat, 15 Feb 2014 13:38:21 -0500

Thanks, I have marked this as HFDU.

On Fri, Sep 6, 2013 at 10:28 AM, Karl Norrman <[email-masked]>wrote:

> Hello!
>
> The observation is correct that the SRTCP index should be padded to 48
> bits here.  This is also indicated in the SRTP FAQ since a few years back.
> Unfortunately the FAQ is not visible enough, so an errata would be better
> to avoid interoperability problems.
>
> http://srtp.sourceforge.net/faq.html
> ...
> Q39. In SRTCP key derivation, does "Replace the SRTP index by the 32-bit
> quantity: 0 || SRTCP index ..." mean that quantity should be padded on the
> left with 16 leading zeros?
>
> A. Yes; the specification means to treat the SRTP index as an unsigned
> integer, in which case the shorter value would be implicitly padded on the
> left with zeros, so that its length matches that of the SRTP index.
> ...
>
> Even if the proposed new text for the errata corrects the problem, I'd
> prefer if we could take the opportunity to clarify the rationale for the
> padding, since it has security significance.
>
> How about making this change instead:
>
> Original  text:
> --------------
> Corrected  text:
> ---------------
> Replace the SRTP index by the 48-bit quantity: 000...0 || 0 || SRTCP index
>  (i.e., excluding the E-bit, replacing it with a fixed 0-bit and padding
> the result
> so that it becomes 48 bits wide to match the size of the SRTP index).
> Since this
> quantity and the SRTP index are both 48 bits wide, the labels are all
> located in
> the same octet in the IV.  The labels for the derivations of the SRTCP keys
> are as follows:   <label> = 0x03 for the SRTCP encryption key, <label> =
> 0x04 for the
> BR
> Karl
> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: den 27 augusti 2013 13:14
> To: [email-masked]; [email-masked]; [email-masked];
> Mats Näslund; Karl Norrman; [email-masked]; Gonzalo Camarillo;
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC3711 (3712)
>
> The following errata report has been submitted for RFC3711, "The Secure
> Real-time Transport Protocol (SRTP)".
>
> Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index(i.e.,
> excluding the E-bit, replacing it with a fixed 0-bit), and use
>
> Corrected Text
> --------------
> Replace the SRTP index by the 48-bit quantity: 0 || SRTCP index(i.e.,
> excluding the E-bit, replacing it with a fixed 0-bit and thenprepending a
> 16-bits zero padding), and use
>
> Notes
> -----
> Replacing with a 32-bit quantity means that the DIV operator willyield a
> 32-bit quantity.  Following the specification of key_id for SRTCPthe
> <label> will have 32 bits to its right when XOR'ing with master_salt.The
> majority of implementations, including libsrtp, invokes this XOR with
> the<label> at the same position as for SRTP.  According to the
> specificationthis should be done 16 bits to the right of this, when
> invoking for SRTCP.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party (IESG) can log in to change the
> status and edit the report, if necessary.
>