Re: [AVTCORE] [Technical Errata Reported] RFC3711 (3712)

[Karl Norrman <[e-mail]>]

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:
--------------
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.

BR
Karl

-----Original Message-----
From: RFC Errata System [mailto:[e-mail]] 
Sent: den 27 augusti 2013 13:14
To: [e-mail]; [e-mail]; [e-mail]; Mats Näslund; Karl Norrman; [e-mail]; Gonzalo Camarillo; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Technical Errata Reported] RFC3711 (3712)

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Christian S Oien <[e-mail]>

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

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. 

--------------------------------------
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