|
From: | Martin Storsjö |
Subject: | Re: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) |
Date: | Thu, 1 Nov 2012 17:31:26 +0200 (EET) |
User-agent: | Alpine 2.00 (DEB 1167 2008-08-23) |
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.hHello 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
[Prev in Thread] | Current Thread | [Next in Thread] |