[PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764)

[Martin Storsjö]

Hi,

On Thu, 1 Nov 2012, Nikos Mavrogiannopoulos wrote:

> On 11/01/2012 12:34 AM, Martin Storsjo wrote:
>
>> ---
>> Implemented what was suggested before, and moved some hunks that I
>> accidentally had placed in patch 2/2 in the previous patchset.
>> ---
>>  NEWS                            |    6 +
>>  doc/Makefile.am                 |   10 +
>>  doc/protocol/rfc5764.txt        | 1459 +++++++++++++++++++++++++++++++++++++++
>>  lib/ext/Makefile.am             |    2 +-
>>  lib/ext/srtp.c                  |  465 +++++++++++++
>>  lib/ext/srtp.h                  |   38 +
>>  lib/gnutls_extensions.c         |    5 +
>>  lib/gnutls_int.h                |    1 +
>>  lib/includes/gnutls/gnutls.h.in |   30 +
>>  lib/libgnutls.map               |    5 +
>>  10 files changed, 2020 insertions(+), 1 deletion(-)
>>  create mode 100644 doc/protocol/rfc5764.txt
>>  create mode 100644 lib/ext/srtp.c
>>  create mode 100644 lib/ext/srtp.h
>
> Hello Martin,
> I've applied it. Thank you. I've done the following changes:
> * gnutls_srtp_set_profile_direct returns GNUTLS_E_INVALID_REQUEST on
> parsing error

Great, thanks!

> * changed the copyright to you until the formal paperwork is finished
> (so we can roll a release with it).

Ok, I got the FSF registration mail a little while ago and I'll post the 
snailmail papers back to FSF soon.

> I've also added a test program in tests/mini-dtls-srtp.c. Could you help
> there with the correct extractor parameters so that this is also checked?

Based on my reading of RFC 5764, one doesn't set any extra context data 
for the extractor, only the label. Or this is at least my interpretation 
of "The per-association context value is empty." in section 4.2 in RFC 
5764 - the one only extracts one single blob of data using the PRF of the 
length given in that section (2 master keys and 2 master salts).

The other interpretation would be using the names 
"client_write_SRTP_master_key" and such as context, but I don't think 
that's the case.

I don't have access to any full setup with DTLS-SRTP yet to test this 
against - I've only tested it against OpenSSL for compatibility with the 
SRTP options one can set there, but I'l still lacking a full setup with 
this integrated into a SRTP stack to test against. I'm hoping to get such 
a test env soon, though.

> Is the key size fixed for each profile? If yes, then wouldn't be easier
> to have a helper function to extract the key, based on the negotiated
> profile?

Yes, the master key size should be 128 bit and the master salt size 112 
bit, so having a function extract all of it at once would be useful. But 
it might be better to hold back on this until I've actually got those 
parts tested against some other reference.

// Martin