[jitsi-dev] SRTCP key derivation


#1

Hello,

I've recently run into a discrepancy between how I understand RFC 3711 and how at least two implementations (jitsi being one of them, libsrtp being the other) perform SRTCP key derivation.

Specifically, section 4.3.1 of RFC 3711 explains how SRTP key derivation works. The key is derived by running "x" through the PRF, where "x" is the right-aligned "key_id" xor'd with the 112-bit salt. The "key_id" in turn is the concatenation of the 8-bit label and "r". "r" in turn is defined as the 48-bit packet index divided by the key derivation rate, which is zero, thus "r" ends up being a 48-bit long zero. Therefore, in an array of 14 octets for the padded and aligned "key_id", this places the label in the 8th octet. All implementations do it this way as well.

The next section, 4.3.2, explains how SRTCP key derivation works. It states that it's the same as for SRTP, except for different labels and that the SRTP packet index is replaced by the 32-bit SRTCP packet index. Now the SRTP packet index was 48 bits long, and now we only have 32 bits worth of packet index. Since "key_id" is the concatenation of the label with "r", and "r" is the same length as the packet index, in my understanding this would put the label in a different spot in "key_id" -- not in the 8th octet, but rather in the 10th, because "r" is only 32 bits long. The result is a different set of SRTCP session keys.

However, implementations disagree, and I'm not sure why. Am I missing something somewhere that would explain this discrepancy? Or am I simply misunderstanding the RFC?

cheers
Richard


#2

Hi Richard

I've recently run into a discrepancy between how I understand RFC 3711
and how at least two implementations (jitsi being one of them, libsrtp
being the other) perform SRTCP key derivation.

Specifically, section 4.3.1 of RFC 3711 explains how SRTP key derivation
works. The key is derived by running "x" through the PRF, where "x" is
the right-aligned "key_id" xor'd with the 112-bit salt. The "key_id" in
turn is the concatenation of the 8-bit label and "r". "r" in turn is
defined as the 48-bit packet index divided by the key derivation rate,
which is zero, thus "r" ends up being a 48-bit long zero. Therefore, in
an array of 14 octets for the padded and aligned "key_id", this places
the label in the 8th octet. All implementations do it this way as well.

The next section, 4.3.2, explains how SRTCP key derivation works. It
states that it's the same as for SRTP, except for different labels and
that the SRTP packet index is replaced by the 32-bit SRTCP packet index.
Now the SRTP packet index was 48 bits long, and now we only have 32 bits
worth of packet index. Since "key_id" is the concatenation of the label
with "r", and "r" is the same length as the packet index, in my
understanding this would put the label in a different spot in "key_id"
-- not in the 8th octet, but rather in the 10th, because "r" is only 32
bits long. The result is a different set of SRTCP session keys.

That would be the obvious result.

However, implementations disagree, and I'm not sure why. Am I missing
something somewhere that would explain this discrepancy? Or am I simply
misunderstanding the RFC?

I'd say the RFC could be better written, but my reading and replies from the
RFC authors in a discussion from 2005 [1] would be the same as yours.

VLC's SRT(C)P implementation [2] follows the RFC.

However the SRTP FAQ [3] from libsrtp says in Q39 that it's meant to be
padded an hence placing the label always at the same position [4]. Given
that libsrtp is kind of the reference implementation (and also from one of
the RFC authors), I guess Werner just followed it to be compatible.

cheers
Richard

Regards,
Ingo

[1] http://www.ietf.org/mail-archive/web/avt/current/msg05692.html
[2] http://git.io/o30S_g
[3] http://srtp.sourceforge.net/faq.html
[4] https://github.com/dswarbrick/libsrtp/blob/master/srtp/srtp.c#L364


#3

I'd say the RFC could be better written, but my reading and replies from the
RFC authors in a discussion from 2005 [1] would be the same as yours.

Funny, I thought it was the other way around, that the RFC was quite
clear but the implementations didn't make sense. :slight_smile:

However the SRTP FAQ [3] from libsrtp says in Q39 that it's meant to be
padded an hence placing the label always at the same position [4]. Given
that libsrtp is kind of the reference implementation (and also from one of
the RFC authors), I guess Werner just followed it to be compatible.

Some good links you posted there, thanks. Good to see that I'm not the
only one who got confused by this, heh. Looks like there's no real
answer to the question (the last person to ask the exact same thing
about this contradiction on the IETF mailing list didn't receive a
reply), so I guess the best choice is to stay compatible with libsrtp.

cheers

···

On 06/26/13 17:51, Ingo Bauersachs wrote:


#4

Well, fresh from David McGrew's lib, here the relevant part that shows it:

err_status_t
srtp_kdf_generate(srtp_kdf_t *kdf, srtp_prf_label label,
      uint8_t *key, int length) {

  v128_t nonce;

  /* set eigth octet of nonce to <label>, set the rest of it to zero */
  v128_set_to_zero(&nonce);
  nonce.v8[7] = label;

  aes_icm_set_iv(&kdf->c, &nonce);

  /* generate keystream output */
  aes_icm_output(&kdf->c, key, length);

  return err_status_ok;
}

Refer to comment: set eigth octet ...

The SRTP lib calls this code to derive the keys for SRTP and for SRTCP, thus the
label is always at the eigth byte.

Werner

···

Am 27.06.2013 15:47, schrieb Richard Fuchs:

On 06/26/13 17:51, Ingo Bauersachs wrote:

I'd say the RFC could be better written, but my reading and replies from the
RFC authors in a discussion from 2005 [1] would be the same as yours.

Funny, I thought it was the other way around, that the RFC was quite
clear but the implementations didn't make sense. :slight_smile:

However the SRTP FAQ [3] from libsrtp says in Q39 that it's meant to be
padded an hence placing the label always at the same position [4]. Given
that libsrtp is kind of the reference implementation (and also from one of
the RFC authors), I guess Werner just followed it to be compatible.

Some good links you posted there, thanks. Good to see that I'm not the
only one who got confused by this, heh. Looks like there's no real
answer to the question (the last person to ask the exact same thing
about this contradiction on the IETF mailing list didn't receive a
reply), so I guess the best choice is to stay compatible with libsrtp.

cheers

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B