gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 57


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]