From INVALID.NOREPLY at gnu.org Mon Oct 1 03:18:19 2012 From: INVALID.NOREPLY at gnu.org (Daniel Black) Date: Mon, 01 Oct 2012 01:18:19 +0000 Subject: [sr #108146] gnutls client tls library not supporting session ticket renewing and aborting In-Reply-To: <20120930-141711.sv707.41471@savannah.gnu.org> References: <20120930-060835.sv89344.61402@savannah.gnu.org> <20120930-061333.sv89344.4351@savannah.gnu.org> <20120930-141711.sv707.41471@savannah.gnu.org> Message-ID: <20121001-011819.sv89344.39403@savannah.gnu.org> Follow-up Comment #3, sr #108146 (project gnutls): thanks for the quick fix. Looked fairly extensive. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Oct 3 11:32:02 2012 From: INVALID.NOREPLY at gnu.org (Alexey Pavlov) Date: Wed, 03 Oct 2012 09:32:02 +0000 Subject: [sr #108150] Fix for the build using mingw64 with winphreads library Message-ID: <20121003-093201.sv89367.82614@savannah.gnu.org> URL: Summary: Fix for the build using mingw64 with winphreads library Project: GnuTLS Submitted by: alexpux Submitted on: ??? 03 ??? 2012 09:32:01 Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: Microsoft Windows _______________________________________________________ Details: strtok_r in winpthread is declared as a macro. Therefore, it is necessary to check whether the macro __WINPTHREADS_VERSION is declared. If so, it is necessary to undefine the strtok_r macro. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: ??? 03 ??? 2012 09:32:01 Name: gnutls-3.1.2-winpthreads-strtok_r.patch Size: 478B By: alexpux patch _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Oct 3 11:56:43 2012 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Wed, 03 Oct 2012 09:56:43 +0000 Subject: [sr #108150] Fix for the build using mingw64 with winphreads library In-Reply-To: <20121003-093201.sv89367.82614@savannah.gnu.org> References: <20121003-093201.sv89367.82614@savannah.gnu.org> Message-ID: <20121003-095643.sv0.79841@savannah.gnu.org> Follow-up Comment #1, sr #108150 (project gnutls): Thank you. Since this also affects the gnulib library, would you like to report it also to upstream? (if not I'll forward your report to them, but I'd prefer not to be the middle man if they have any questions) http://www.gnu.org/software/gnulib/ regards, Nikos _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Oct 3 12:39:12 2012 From: INVALID.NOREPLY at gnu.org (Alexey Pavlov) Date: Wed, 03 Oct 2012 10:39:12 +0000 Subject: [sr #108150] Fix for the build using mingw64 with winphreads library In-Reply-To: <20121003-095643.sv0.79841@savannah.gnu.org> References: <20121003-093201.sv89367.82614@savannah.gnu.org> <20121003-095643.sv0.79841@savannah.gnu.org> Message-ID: <20121003-103912.sv89367.27712@savannah.gnu.org> Follow-up Comment #2, sr #108150 (project gnutls): I rebuild gnutls and correct the patch. (file #26685) _______________________________________________________ Additional Item Attachment: File name: gnutls-3.1.2-winpthreads-strtok_r.patch Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Oct 4 15:26:47 2012 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Thu, 04 Oct 2012 13:26:47 +0000 Subject: [sr #107806] Build failure for gnutls >= 3.0.1 under Mac OS X In-Reply-To: <20110928-232908.sv707.46934@savannah.gnu.org> References: <20110918-224837.sv63226.24405@savannah.gnu.org> <20110920-005523.sv707.96496@savannah.gnu.org> <20110920-003854.sv63226.26497@savannah.gnu.org> <20110921-140033.sv7213.74553@savannah.gnu.org> <20110921-234843.sv63226.16101@savannah.gnu.org> <20110925-204114.sv707.88114@savannah.gnu.org> <20110925-201718.sv63226.28785@savannah.gnu.org> <20110926-123328.sv0.54448@savannah.gnu.org> <20110928-232908.sv707.46934@savannah.gnu.org> Message-ID: <20121004-132646.sv0.893@savannah.gnu.org> Follow-up Comment #8, sr #107806 (project gnutls): This reappeared with gnutls 3.1.2, this time in lib/nettle/wmnaf.c. Adding #include makes it compile again. Patch attached. (file #26698) _______________________________________________________ Additional Item Attachment: File name: gnutls-3.1.2-struct-option.patch Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Oct 4 19:25:54 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 04 Oct 2012 17:25:54 +0000 Subject: [sr #107806] Build failure for gnutls >= 3.0.1 under Mac OS X In-Reply-To: <20121004-132646.sv0.893@savannah.gnu.org> References: <20110918-224837.sv63226.24405@savannah.gnu.org> <20110920-005523.sv707.96496@savannah.gnu.org> <20110920-003854.sv63226.26497@savannah.gnu.org> <20110921-140033.sv7213.74553@savannah.gnu.org> <20110921-234843.sv63226.16101@savannah.gnu.org> <20110925-204114.sv707.88114@savannah.gnu.org> <20110925-201718.sv63226.28785@savannah.gnu.org> <20110926-123328.sv0.54448@savannah.gnu.org> <20110928-232908.sv707.46934@savannah.gnu.org> <20121004-132646.sv0.893@savannah.gnu.org> Message-ID: <20121004-202554.sv707.3368@savannah.gnu.org> Follow-up Comment #9, sr #107806 (project gnutls): Thanks. Applied. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From vzell at volkerzell.de Thu Oct 4 15:08:11 2012 From: vzell at volkerzell.de (Dr. Volker Zell) Date: Thu, 04 Oct 2012 15:08:11 +0200 Subject: gnutls-3.1.2 build failure when generating HTML doc Message-ID: <87a9w2s7us.fsf@oracle.com> Hi With the latest release of gnutls-3.1.2 it doesn't build cleanly anymore on cygwin. lots of warning: No declaration found messages ./gnutls-sections.txt:2656: warning: No declaration found for RIPEMD160_Final. ./gnutls-sections.txt:2657: warning: No declaration found for RIPEMD160. See gnutls-undeclared.txt for the list of undeclared symbols. ./gnutls-unused.txt:1: warning: 103 unused declarations.They should be added to gnutls-sections.txt in the appropriate place. DOC Building HTML warning: failed to load external entity "../xml/dtls.xml" ../gnutls-docs.sgml:36: element include: XInclude error : could not load ../xml/dtls.xml, and no fallback was found warning: failed to load external entity "../xml/ocsp.xml" ../gnutls-docs.sgml:40: element include: XInclude error : could not load ../xml/ocsp.xml, and no fallback was found warning: failed to load external entity "../xml/tpm.xml" ../gnutls-docs.sgml:41: element include: XInclude error : could not load ../xml/tpm.xml, and no fallback was found Makefile:1898: recipe for target `html-build.stamp' failed make[4]: *** [html-build.stamp] Error 6 make[4]: Leaving directory `/cygdrive/d/misc/src/release/gnutls-3.1.2-1/build/doc/reference' Makefile:3504: recipe for target `all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/cygdrive/d/misc/src/release/gnutls-3.1.2-1/build/doc' Makefile:3200: recipe for target `all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory `/cygdrive/d/misc/src/release/gnutls-3.1.2-1/build/doc' Makefile:1592: recipe for target `all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/d/misc/src/release/gnutls-3.1.2-1/build' Makefile:1519: recipe for target `all' failed make: *** [all] Error 2 The previous build of version gnutls-3.1.1 gives ./gnutls-sections.txt:2656: warning: No declaration found for RIPEMD160_Final. ./gnutls-sections.txt:2657: warning: No declaration found for RIPEMD160. See gnutls-undeclared.txt for the list of undeclared symbols. ./gnutls-unused.txt:1: warning: 92 unused declarations.They should be added to gnutls-sections.txt in the appropriate place. DOC Building HTML warning: failed to load external entity "../xml/dtls.xml" ../gnutls-docs.sgml:36: element include: XInclude error : could not load ../xml/dtls.xml, and no fallback was found warning: failed to load external entity "../xml/ocsp.xml" ../gnutls-docs.sgml:40: element include: XInclude error : could not load ../xml/ocsp.xml, and no fallback was found Element include in namespace 'http://www.w3.org/2003/XInclude' encountered in chapter, but no template matches. Element include in namespace 'http://www.w3.org/2003/XInclude' encountered in chapter, but no template matches. DOC Fixing cross-references make[4]: Leaving directory `/cygdrive/d/misc/src/release/gnutls-3.1.1-1/build/doc/reference' make[4]: Entering directory `/cygdrive/d/misc/src/release/gnutls-3.1.1-1/build/doc' Ciao Volker From nmav at gnutls.org Sun Oct 7 00:09:07 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 07 Oct 2012 00:09:07 +0200 Subject: gnutls-3.1.2 build failure when generating HTML doc In-Reply-To: <87a9w2s7us.fsf@oracle.com> References: <87a9w2s7us.fsf@oracle.com> Message-ID: <5070AC03.9080400@gnutls.org> On 10/04/2012 03:08 PM, Dr. Volker Zell wrote: > Hi > > With the latest release of gnutls-3.1.2 it doesn't build cleanly anymore on cygwin. > lots of warning: No declaration found messages There is an issue with the gtk-doc documentation. I have no time to check it out though. Just ignore this error. regards, Nikos From INVALID.NOREPLY at gnu.org Mon Oct 8 12:05:16 2012 From: INVALID.NOREPLY at gnu.org (Ochir) Date: Mon, 08 Oct 2012 10:05:16 +0000 Subject: [sr #108152] gnutls 3.1.2 mingw64 issue with compiling 64 bit library Message-ID: <20121008-100515.sv89409.44734@savannah.gnu.org> URL: Summary: gnutls 3.1.2 mingw64 issue with compiling 64 bit library Project: GnuTLS Submitted by: ochir Submitted on: Mon 08 Oct 2012 10:05:15 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: gnutls 3.1.2, nettle 2.5. Configuration options: configure: summary of build options: version: 3.1.2 shared 40:0:12 Host type: x86_64-w64-mingw32 Install prefix: /var/lib/jenkins/jobs/Gnutls4Win/workspace/result-64 Compiler: x86_64-w64-mingw32-gcc -std=gnu99 CFlags: -I/var/lib/jenkins/jobs/Gnutls4Win/workspace/result-64/include -L/var/lib/jenkins/jobs/Gnutls4Win/workspace/result-64/lib Warning flags: errors: warnings: Library types: Shared=no, Static=yes Valgrind: no configure: Optional features: (note that included applications might not compile properly if features are disabled) OCSP support: yes OpenPGP support: yes SRP support: yes PSK support: yes Anon auth support:yes Trust store pkcs: Trust store file: /etc/ssl/certs/ca-certificates.crt CRL file: configure: Optional applications: crywrap app: local libopts: yes configure: Optional libraries: Guile wrappers: no C++ library: no OpenSSL compat: no configure: Hardware acceleration/support: /dev/crypto: no Hardware accel: x86-64 PKCS#11 support: no TPM support: no 32 bit library compiles successfully. After compilation of 64 bit library the following error displays: ... ../../lib/system.c: In function 'gnutls_x509_trust_list_add_system_trust': ../../lib/system.c:429:5: warning: implicit declaration of function 'Loaded_CertEnumCRLsInStore' [-Wimplicit-function-declaration] ../../lib/system.c:429:9: warning: assignment makes pointer from integer without a cast [enabled by default] ../../lib/system.c:451:13: warning: assignment makes pointer from integer without a cast [enabled by default] CC gnutls_str.lo CC gnutls_state.lo CC gnutls_x509.lo CC gnutls_rsa_export.lo CC gnutls_helper.lo CC gnutls_supplemental.lo CC random.lo CC crypto-api.lo CC gnutls_privkey.lo CC gnutls_pcert.lo CC gnutls_pubkey.lo CC locks.lo CC hash.lo CC gnutls_dtls.lo CC system_override.lo CC crypto-backend.lo CC verify-tofu.lo CC pin.lo CC gnutls_srp.lo CC gnutls_psk.lo CCLD libgnutls.la copying selected object files to avoid basename conflicts... make[1]: Leaving directory `/var/lib/jenkins/jobs/Gnutls4Win/workspace/build/gnutls-3.1.2/build-64/lib' make: Leaving directory `/var/lib/jenkins/jobs/Gnutls4Win/workspace/build/gnutls-3.1.2/build-64/lib' obj/system.o:system.c:(.text+0x4d2): undefined reference to `Loaded_CertEnumCRLsInStore' obj/system.o:system.c:(.text+0x5a8): undefined reference to `Loaded_CertEnumCRLsInStore' collect2: ld returned 1 exit status _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Oct 9 19:54:55 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 09 Oct 2012 17:54:55 +0000 Subject: [sr #108152] gnutls 3.1.2 mingw64 issue with compiling 64 bit library In-Reply-To: <20121008-100515.sv89409.44734@savannah.gnu.org> References: <20121008-100515.sv89409.44734@savannah.gnu.org> Message-ID: <20121009-205455.sv707.45675@savannah.gnu.org> Update of sr #108152 (project gnutls): Status: None => Ready For Test Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Indeed. It seems something is missing there. Does the attached patch fix the issue for you? (file #26726) _______________________________________________________ Additional Item Attachment: File name: patch.txt Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Oct 10 00:42:21 2012 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Tue, 09 Oct 2012 22:42:21 +0000 Subject: [sr #108155] GnuTLS doesn't accept passwords larger than 32; NSS and OpenSSL do Message-ID: <20121009-224220.sv0.36326@savannah.gnu.org> URL: Summary: GnuTLS doesn't accept passwords larger than 32; NSS and OpenSSL do Project: GnuTLS Submitted by: None Submitted on: Tue 09 Oct 2012 10:42:20 PM UTC Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: jclinton at google.com Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: > _gnutls_pkcs12_string_to_key(): > pwlen = strlen (pw); > if (pwlen > 63 / 2) > { > gnutls_assert (); > return GNUTLS_E_INVALID_REQUEST; > } Compatibility issue between NSS, OpenSSL and GnuTLS. Because of the above snippet, passwords larger than 32 characters work fine in the former two; fail in GnuTLS. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Oct 10 11:42:32 2012 From: INVALID.NOREPLY at gnu.org (Ochir) Date: Wed, 10 Oct 2012 09:42:32 +0000 Subject: [sr #108152] gnutls 3.1.2 mingw64 issue with compiling 64 bit library In-Reply-To: <20121009-205455.sv707.45675@savannah.gnu.org> References: <20121008-100515.sv89409.44734@savannah.gnu.org> <20121009-205455.sv707.45675@savannah.gnu.org> Message-ID: <20121010-094232.sv89409.48971@savannah.gnu.org> Follow-up Comment #2, sr #108152 (project gnutls): Now it works. Thank you. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Oct 10 20:13:44 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 10 Oct 2012 18:13:44 +0000 Subject: [sr #108155] GnuTLS doesn't accept passwords larger than 32; NSS and OpenSSL do In-Reply-To: <20121009-224220.sv0.36326@savannah.gnu.org> References: <20121009-224220.sv0.36326@savannah.gnu.org> Message-ID: <20121010-211343.sv707.19938@savannah.gnu.org> Follow-up Comment #1, sr #108155 (project gnutls): Does the attached patch fix the issue for you? Could you verify that the longer passwords are compatible with NSS and openssl? regards, Nikos (file #26734) _______________________________________________________ Additional Item Attachment: File name: pkcs12.patch Size:2 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From mk at cognitivedissonance.ca Fri Oct 12 13:38:41 2012 From: mk at cognitivedissonance.ca (MK) Date: Fri, 12 Oct 2012 07:38:41 -0400 Subject: Error in documentation Message-ID: <20121012073841.13bbde4307405f34e02a4c01@cognitivedissonance.ca> In the description of gnutls_global_set_audit_log_func, it says: gnutls_audit_log_func is of the form, void (*gnutls_audit_log_func) ( gnutls_session_t, int level, const char*); This isn't true and leads to a compiler warning (good thing you defined a type for the pointer!) and of course confusing behaviour. gnutls_audit_log_func is actually defined in gnutls.h as: void (*gnutls_audit_log_func) (gnutls_session_t, const char *) Thanks -- MK -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin) From nmav at gnutls.org Fri Oct 12 16:40:00 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Oct 2012 16:40:00 +0200 Subject: Error in documentation In-Reply-To: <20121012073841.13bbde4307405f34e02a4c01@cognitivedissonance.ca> References: <20121012073841.13bbde4307405f34e02a4c01@cognitivedissonance.ca> Message-ID: <50782BC0.8070008@gnutls.org> On 10/12/2012 01:38 PM, MK wrote: > In the description of gnutls_global_set_audit_log_func, it says: > > gnutls_audit_log_func is of the form, void (*gnutls_audit_log_func) > ( gnutls_session_t, int level, const char*); > > This isn't true and leads to a compiler warning (good thing you defined > a type for the pointer!) and of course confusing behaviour. > > gnutls_audit_log_func is actually defined in gnutls.h as: > > void (*gnutls_audit_log_func) (gnutls_session_t, const char *) Thanks. Updated. regards, Nikos From nmav at gnutls.org Fri Oct 12 19:08:15 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Oct 2012 19:08:15 +0200 Subject: gnutls 3.0.25 Message-ID: <50784E7F.6060206@gnutls.org> Hello, I've just released gnutls 3.0.25. This is a bug-fix release on the old stable branch. * Version 3.0.25 (released 2012-10-12) ** libgnutls: Fixed the receipt of session tickets during session resumption. Reported by danblack at http://savannah.gnu.org/support/?108146 ** libgnutls: Added gnutls_ocsp_resp_check_crt() to check whether the OCSP response corresponds to the given certificate. ** libgnutls: Several updates in the OpenPGP code. The generating code is fully RFC6091 compliant and RFC5081 support is only supported in client mode. ** API and ABI modifications: gnutls_ocsp_resp_check_crt: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Oct 12 19:20:38 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Oct 2012 19:20:38 +0200 Subject: gnutls 3.1.3 Message-ID: <50785166.2050200@gnutls.org> Hello, I've just released gnutls 3.1.3. This release includes initial support for the DANE protocol and the OCSP status request TLS extension. The DANE protocol is an IETF protocol to verify certificates using DNSSEC. * Version 3.1.3 (released 2012-10-12) ** libgnutls: Added support for the OCSP Certificate Status extension. ** libgnutls: gnutls_certificate_verify_peers2() will use the OCSP certificate status extension in verification. ** libgnutls: Bug fixes in gnutls_x509_privkey_import_openssl(). ** libgnutls: Increased maximum password length in the PKCS #12 functions. ** libgnutls: Fixed the receipt of session tickets during session resumption. Reported by danblack at http://savannah.gnu.org/support/?108146 ** libgnutls: Added functions to export structures in an allocated buffer. ** libgnutls: Added gnutls_ocsp_resp_check_crt() to check whether the OCSP response corresponds to the given certificate. ** libgnutls: In client side gnutls_init() enables the session ticket and OCSP certificate status request extensions by default. The flag GNUTLS_NO_EXTENSIONS can be used to prevent that. ** libgnutls: Several updates in the OpenPGP code. The generating code is fully RFC6091 compliant and RFC5081 support is only supported in client mode. ** libgnutls-dane: Added. It is a library to provide DANE with DNSSEC certificate verification. ** gnutls-cli: Added --dane option to enable DANE certificate verification. ** danetool: Added tool to generate DANE TLSA Resource Records (RR). ** API and ABI modifications: gnutls_certificate_get_peers_subkey_id: Added gnutls_certificate_set_ocsp_status_request_function: Added gnutls_certificate_set_ocsp_status_request_file: Added gnutls_ocsp_status_request_enable_client: Added gnutls_ocsp_status_request_get: Added gnutls_ocsp_resp_check_crt: Added gnutls_dh_params_export2_pkcs3: Added gnutls_pubkey_export2: Added gnutls_x509_crt_export2: Added gnutls_x509_dn_export2: Added gnutls_x509_crl_export2: Added gnutls_pkcs7_export2: Added gnutls_x509_privkey_export2: Added gnutls_x509_privkey_export2_pkcs8: Added gnutls_x509_crq_export2: Added gnutls_openpgp_crt_export2: Added gnutls_openpgp_privkey_export2: Added gnutls_pkcs11_obj_export2: Added gnutls_pkcs12_export2: Added gnutls_pubkey_import_openpgp_raw: Added gnutls_pubkey_import_x509_raw: Added dane_state_init: Added dane_state_deinit: Added dane_query_tlsa: Added dane_query_status: Added dane_query_entries: Added dane_query_data: Added dane_query_deinit: Added dane_verify_session_crt: Added dane_verify_crt: Added dane_strerror: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From INVALID.NOREPLY at gnu.org Sat Oct 13 20:24:34 2012 From: INVALID.NOREPLY at gnu.org (James Cloos) Date: Sat, 13 Oct 2012 18:24:34 +0000 Subject: [sr #108160] gnutls-cli should expose =?UTF-8?B?bGliZGFuZeKAmXM=?= resolv.conf option Message-ID: <20121013-182434.sv4735.32943@savannah.gnu.org> URL: Summary: gnutls-cli should expose libdane?s resolv.conf option Project: GnuTLS Submitted by: cloos Submitted on: Sat 13 Oct 2012 06:24:34 PM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: One should be able to select whether to honour resolv.conf when using gnutls-cli. Perhaps, iff the first entry is 127.0.0.1 or ::1, it should be on by default. (Or maybe that and whether to cache by default should be compile-time options?) The advantage of a local cache is *very* important when bandwidth is limited. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sat Oct 13 20:44:22 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 13 Oct 2012 18:44:22 +0000 Subject: [sr #108160] gnutls-cli should expose =?UTF-8?B?bGliZGFuZeKAmXM=?= resolv.conf option In-Reply-To: <20121013-182434.sv4735.32943@savannah.gnu.org> References: <20121013-182434.sv4735.32943@savannah.gnu.org> Message-ID: <20121013-214422.sv707.26277@savannah.gnu.org> Update of sr #108160 (project gnutls): Status: None => Confirmed Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Indeed an option to use the default dns server should be added. I set the default however not to be the local cache because I've noticed that in many systems the DNS servers do not allow DNSSEC. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Oct 14 21:54:42 2012 From: INVALID.NOREPLY at gnu.org (Elias Pipping) Date: Sun, 14 Oct 2012 19:54:42 +0000 Subject: [sr #108161] The pkcs12 test fails when srcdir != builddir Message-ID: <20121014-195441.sv76013.50583@savannah.gnu.org> URL: Summary: The pkcs12 test fails when srcdir != builddir Project: GnuTLS Submitted by: pipping Submitted on: Sun 14 Oct 2012 07:54:41 PM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: The pkcs12 test fails with out-of-source builds. I've attached a fix. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Sun 14 Oct 2012 07:54:41 PM GMT Name: 0001-Fix-out-of-source-tests.patch Size: 1kB By: pipping _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From sse.auburn.study at gmail.com Sun Oct 14 07:47:01 2012 From: sse.auburn.study at gmail.com (Auburn Study) Date: Sun, 14 Oct 2012 00:47:01 -0500 Subject: Buffer Overflow Study at Auburn University - GnuTLS developers I would really appreciate your help! Message-ID: Hi All, I am a graduate student at Auburn University, working with Dr. Munawar Hafiz on an empirical study project to understand the software engineering practices used in companies that produce secure software. In particular, we are concentrating on how developers write code to prevent buffer overflow and integer overflow vulnerabilities. We are interested in the software development process: how you develop software, how you test and analyze programs to detect vulnerabilities, and what processes you follow to remove bugs. We are looking into automated tools that software developers use, and are expecting that there is a common insight in the security engineering process that can be reusable. We request your assistance by participating in this research study. We would greatly appreciate it if you would share your experience with us by answering the questions at the end of this email. We may send some follow up questions based on your response in future. Your response(s) will be kept confidential, and will only be aggregated with those of other reporters. Please let us know if you have any questions or concerns regarding the study. Thanks in advance for your support. Yasmeen Rawajfih Software Analysis, Transformations and Security Group Auburn University Working under the supervision of: Dr. Munawar Hafiz Assistant Professor Dept. of Computer Science and Software Engineering Auburn University Auburn, AL http://munawarhafiz.com/ Questions: (There are ten questions.) 1. How long have you been a software developer? 2. How long have you been affiliated with GnuTLS? Were you part of the original development team for this software? 3. What is the size of the current code base? 4. Did you follow a coding standard when developing this software? Is it a standard determined by your group? 5. What did you use to manage bug reports in your software? Does it satisfy your requirements? Are there other software options that you would consider switching to? 6. Did you use any compiler options to detect integer overflow vulnerabilities? Do you think that they are useful? 7. Did you use any automated (static or dynamic analysis) tools to detect buffer overflows, integer overflows, or any other bugs? Which tools did you use? Why these tools? 8. Did you use fuzzing? Which tools did you use and why? If you wrote your own fuzzer, why did you write it yourself? Was it written from scratch or by extending some other fuzzing tools? 9. Did you have specific phases during development where you concentrated on fixing security issues? Did you have a test suite, unit tests, or regression tests? 10. Buffer overflows often result from the use of unsafe functions, such as strcpy. Does your software use those? If you use a different string library, why is it used? Is it an in-house library or an off-the-shelf library? Did you migrate your code to use the string library? -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald.v.sullivan at nasa.gov Wed Oct 24 03:49:06 2012 From: donald.v.sullivan at nasa.gov (Don Sullivan) Date: Tue, 23 Oct 2012 18:49:06 -0700 Subject: DTLS Server Message-ID: <50874912.1040108@nasa.gov> Build of the DTLS server is disabled in both gnutls-3.0.25 and gnutls-3.1.3. Why ? When I try to build it, ex-client-dtls segfaults on the handshake (both versions) Suggestions ? In advance, Thank You ! Don -- --------------------------------------------- Don Sullivan NASA Ames Research Center Bldg N245, Rm 131a/MS 245-4 P.O. Box 1 Moffett Field, CA 94035-0001 Office: +1 650 604 0526 Mobile: +1 650 714 9742 Line2: +1 831 621 5023 email: donald.v.sullivan at nasa.gov OR: yes_its_don at mac.com --------------------------------------------- - Sic gorgiamus allos subjectatos nunc "Scientists seek to understand what is, engineers seek to create what never was." - Theodore Karman -------------- next part -------------- A non-text attachment was scrubbed... Name: donald_v_sullivan.vcf Type: text/x-vcard Size: 325 bytes Desc: not available URL: From mark.thornber at gmail.com Wed Oct 24 12:11:15 2012 From: mark.thornber at gmail.com (Mark Thornber) Date: Wed, 24 Oct 2012 11:11:15 +0100 Subject: `make distclean` Unexpected end of line seen Message-ID: gnutls 3.1.1 in "doc/reference", 3.1.3 in "doc" Solaris 10 gcc 3.4.6 (sunfreeware pkg) cd gnutls-3.1.x ./configure make make check make distclean -- Mark Thornber -------------- next part -------------- Making distclean in doc Making distclean in reference make: Fatal error in reader: Makefile, line 2016: Unexpected end of line seen Current working directory /export/home/thornbem/work/gnutls/gnutls-3.1.1/doc/reference *** Error code 1 The following command caused the error: fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ case "distclean-recursive" in \ distclean-* | maintainer-clean-*) list='examples cyclo scripts manpages credentials latex reference' ;; \ *) list='examples cyclo scripts manpages credentials latex ' ;; \ esac; \ rev=''; for subdir in $list; do \ if test "$subdir" = "."; then :; else \ rev="$subdir $rev"; \ fi; \ done; \ rev="$rev ."; \ target=`echo distclean-recursive | sed s/-recursive//`; \ for subdir in $rev; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ || eval $failcom; \ done && test -z "$fail" make: Fatal error: Command failed for target `distclean-recursive' Current working directory /export/home/thornbem/work/gnutls/gnutls-3.1.1/doc *** Error code 1 The following command caused the error: fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ case "distclean-recursive" in \ distclean-* | maintainer-clean-*) list='gl lib extra po src doc tests guile' ;; \ *) list='gl lib extra po src doc tests ' ;; \ esac; \ rev=''; for subdir in $list; do \ if test "$subdir" = "."; then :; else \ rev="$subdir $rev"; \ fi; \ done; \ rev="$rev ."; \ target=`echo distclean-recursive | sed s/-recursive//`; \ for subdir in $rev; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ || eval $failcom; \ done && test -z "$fail" make: Fatal error: Command failed for target `distclean-recursive' From mark.thornber at gmail.com Wed Oct 24 12:21:53 2012 From: mark.thornber at gmail.com (Mark Thornber) Date: Wed, 24 Oct 2012 11:21:53 +0100 Subject: `make check` fails with segmentation fault Message-ID: gnutls-3.1.1 Solaris 10 (from sunfreeware packages) gcc 3.4.6 gmp 4.2.1 nettle 2.5 (gnutls-provided libtasn1) Compilation failed in lib/nettle/wmnaf.c originally Eye-balled the commitdiff changes to this source file and made same changes locally. Also updated lib/ext/max_record.c, lib/gnutls_buffers.c, and lib/gnutls_int.h with changes that were part of same commits cd gnutls-3.1.1 ./configure make make check First set of tests all passed (or were skipped) Second set 10 out of 62 failed attached file contains output from first two failures. All others due to same problem -- Mark Thornber -------------- next part -------------- PASS: pkcs12_encode bash: line 5: 18899 Segmentation Fault (core dumped) CAFILE=./cert-tests/ca-certs.pem PKCS12_MANY_CERTS_FILE=./pkcs12-decode/pkcs12_5certs.p12 PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT= srcdir="." ${dir}$tst FAIL: mini-x509 bash: line 5: 18904 Segmentation Fault (core dumped) CAFILE=./cert-tests/ca-certs.pem PKCS12_MANY_CERTS_FILE=./pkcs12-decode/pkcs12_5certs.p12 PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT= srcdir="." ${dir}$tst FAIL: mini-rehandshake PASS: rng-fork From mark.thornber at gmail.com Wed Oct 24 14:39:18 2012 From: mark.thornber at gmail.com (Mark Thornber) Date: Wed, 24 Oct 2012 13:39:18 +0100 Subject: Irritating build warnings Message-ID: gnutls 3.1.1 (but problems are still there in 3.1.3) Solaris 10 gcc 3.4.6 installed from sunfreeware Warning 1 / CC ecc_projective_add_point.lo In file included from ./../gnutls_int.h:27, from ecc.h:25, from ecc_projective_add_point.c:25: ../../config.h:2460:1: warning: "_FILE_OFFSET_BITS" redefined In file included from /usr/include/sys/int_types.h:34, from /usr/include/sys/stdint.h:17, from /usr/include/stdint.h:17, from ./../../gl/stdint.h:78, from /usr/local/include/nettle/nettle-stdint.h:11, from /usr/local/include/nettle/nettle-types.h:29, from ecc.h:22, from ecc_projective_add_point.c:25: /usr/include/sys/feature_tests.h:188:1: warning: this is the location of the previous definition CC ecc_projective_add_point_ng.lo This warning occurs many times Warning 2 CCLD gnutls-serv ld: warning: global symbol `_END_' has non-global binding: (file /usr/local/lib/libiconv.so value=LOCL); ld: warning: global symbol `_START_' has non-global binding: (file /usr/local/lib/libiconv.so value=LOCL); CC cli.o This warning occurs many times. However I wonder if this is an artifact of linking on Solaris 10. Warning 3 (C and C++) CCLD certtool ld: warning: file /export/home/thornbem/work/gnutls/gnutls-3.1.1/lib/.libs/libgnutls.so: linked to ../lib/.libs/libgnutls.so: attempted multiple inclusion of file CXXLD ex-cxx ld: warning: file /export/home/thornbem/work/gnutls/gnutls-3.1.1/lib/.libs/libgnutls.so: linked to ../../lib/.libs/libgnutls.so: attempted multiple inclusion of file ld: warning: global symbol `_END_' has non-global binding: (file /usr/local/lib/libiconv.so value=LOCL); ld: warning: global symbol `_START_' has non-global binding: (file /usr/local/lib/libiconv.so value=LOCL); ld: warning: file /usr/local/lib/libstdc++.so: attempted multiple inclusion of file -- Mark Thornber From nmav at gnutls.org Sun Oct 28 02:34:53 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 28 Oct 2012 02:34:53 +0100 Subject: Irritating build warnings In-Reply-To: References: Message-ID: <508C8BBD.9040308@gnutls.org> On 10/24/2012 02:39 PM, Mark Thornber wrote: > gnutls 3.1.1 (but problems are still there in 3.1.3) > > Solaris 10 > gcc 3.4.6 installed from sunfreeware > > Warning 1 > / > CC ecc_projective_add_point.lo > In file included from ./../gnutls_int.h:27, > from ecc.h:25, > from ecc_projective_add_point.c:25: > ../../config.h:2460:1: warning: "_FILE_OFFSET_BITS" redefined > In file included from /usr/include/sys/int_types.h:34, > from /usr/include/sys/stdint.h:17, > from /usr/include/stdint.h:17, > from ./../../gl/stdint.h:78, > from /usr/local/include/nettle/nettle-stdint.h:11, > from /usr/local/include/nettle/nettle-types.h:29, > from ecc.h:22, > from ecc_projective_add_point.c:25: > /usr/include/sys/feature_tests.h:188:1: warning: this is the location > of the previous definition > CC ecc_projective_add_point_ng.lo > Hello, Do you use the latest version of nettle? Otherwise since I don't have a solaris, any suggested fix? regards, Nikos From nmav at gnutls.org Sun Oct 28 02:37:14 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 28 Oct 2012 02:37:14 +0100 Subject: `make check` fails with segmentation fault In-Reply-To: References: Message-ID: <508C8C4A.2090705@gnutls.org> On 10/24/2012 12:21 PM, Mark Thornber wrote: > gnutls-3.1.1 > > Solaris 10 > > (from sunfreeware packages) > gcc 3.4.6 > gmp 4.2.1 > nettle 2.5 > > (gnutls-provided libtasn1) > > > Compilation failed in lib/nettle/wmnaf.c originally > Eye-balled the commitdiff changes to this source file and made same > changes locally. Also updated lib/ext/max_record.c, > lib/gnutls_buffers.c, and lib/gnutls_int.h with changes that were part > of same commits > First set of tests all passed (or were skipped) > Second set 10 out of 62 failed > attached file contains output from first two failures. All others due > to same problem Hello, It seems there is an issue in the library built in your system. Could you try taking a backtrace or run those tests under valgrind? regards, Nikos From INVALID.NOREPLY at gnu.org Sun Oct 28 02:39:31 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 28 Oct 2012 01:39:31 +0000 Subject: [sr #108161] The pkcs12 test fails when srcdir != builddir In-Reply-To: <20121014-195441.sv76013.50583@savannah.gnu.org> References: <20121014-195441.sv76013.50583@savannah.gnu.org> Message-ID: <20121028-033931.sv707.56165@savannah.gnu.org> Update of sr #108161 (project gnutls): Status: None => Done Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Applied. Thank you. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sun Oct 28 02:41:51 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 28 Oct 2012 02:41:51 +0100 Subject: DTLS Server In-Reply-To: <50874912.1040108@nasa.gov> References: <50874912.1040108@nasa.gov> Message-ID: <508C8D5F.8090302@gnutls.org> On 10/24/2012 03:49 AM, Don Sullivan wrote: > Build of the DTLS server is disabled in both gnutls-3.0.25 and gnutls-3.1.3. > Why ? Hello, I do not understand what do you mean by disabled. As it is currently DTLS cannot be disabled. Could you be more specific? > When I try to build it, ex-client-dtls segfaults on the handshake (both versions) > Suggestions ? Could you try valgrind on this example? regards, Nikos From nmav at gnutls.org Sun Oct 28 14:55:58 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 28 Oct 2012 14:55:58 +0100 Subject: GNU Libtasn1 3.0 released Message-ID: <508D396E.2030804@gnutls.org> GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. This release includes several optimizations which provide a significant performance boost in the library. * Noteworthy changes in release 3.0 (2012-10-28) [stable] - Added tool in tests/ to benchmark X.509 structure decoding. - Added asn1_read_node_value() to obtain a node's value. - Optimizations in internal tree allocation. - Optimizations in tree search. - libtasn1.h no longer exports internal structures. - Types were renamed for consistency: ASN1_DATA_NODE -> asn1_data_node_st ASN1_ARRAY_TYPE -> asn1_static_node ASN1_TYPE -> asn1_node ASN1_TYPE_EMPTY -> NULL static_struct_asn -> asn1_static_node_st node_asn_struct -> asn1_node_st node_asn -> asn1_node_st (the old types are still available as definitions) Homepage: https://www.gnu.org/software/libtasn1/ Here are the compressed sources: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz Here are GPG detached signatures: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz.sig If you need help to use Libtasn1, or want to help others, you are invited to join the help-libtasn1 mailing list, see: https://lists.gnu.org/mailman/listinfo/help-libtasn1 All manuals are available from: https://www.gnu.org/software/libtasn1/manual/ Direct links to the manual: HTML: https://www.gnu.org/software/libtasn1/manual/libtasn1.html PDF: https://www.gnu.org/software/libtasn1/manual/libtasn1.pdf Direct links to the API Reference manual: HTML: https://www.gnu.org/software/libtasn1/reference/ PDF: https://www.gnu.org/software/libtasn1/reference/libtasn1.pdf For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: https://www.gnu.org/software/libtasn1/cyclo/ Code coverage charts indicate parts of the source code that needs to be tested better by the included self-tests: https://www.gnu.org/software/libtasn1/coverage/ Clang can analyse the source code for common problems, here is its report for libtasn1: https://www.gnu.org/software/libtasn1/clang/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sun Oct 28 23:42:20 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 28 Oct 2012 23:42:20 +0100 Subject: GNU Libtasn1 3.0 released In-Reply-To: <508D396E.2030804@gnutls.org> References: <508D396E.2030804@gnutls.org> Message-ID: <508DB4CC.10406@gnutls.org> On 10/28/2012 02:55 PM, Nikos Mavrogiannopoulos wrote: > Homepage: > https://www.gnu.org/software/libtasn1/ > Here are the compressed sources: > ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz > http://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz And actually they are not there yet. I've prematurely sent the e-mail. I've temporarily placed the archives at: ftp://ftp.hellug.gr/pub/gnutls/libtasn1/ regards, Nikos From nmav at gnutls.org Mon Oct 29 19:27:37 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Oct 2012 19:27:37 +0100 Subject: GNU Libtasn1 3.0 released In-Reply-To: <508DB4CC.10406@gnutls.org> References: <508D396E.2030804@gnutls.org> <508DB4CC.10406@gnutls.org> Message-ID: <508ECA99.6010400@gnutls.org> On 10/28/2012 11:42 PM, Nikos Mavrogiannopoulos wrote: >> Homepage: >> https://www.gnu.org/software/libtasn1/ >> Here are the compressed sources: >> ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz >> http://ftp.gnu.org/gnu/libtasn1/libtasn1-3.0.tar.gz > > > And actually they are not there yet. I've prematurely sent the e-mail. The download links should work now. regards, Nikos From martin at martin.st Mon Oct 29 14:44:26 2012 From: martin at martin.st (Martin Storsjo) Date: Mon, 29 Oct 2012 15:44:26 +0200 Subject: [PATCH 2/2] examples: Build an executable of ex-serv-dtls like the other examples In-Reply-To: <1351518266-84025-1-git-send-email-martin@martin.st> References: <1351518266-84025-1-git-send-email-martin@martin.st> Message-ID: <1351518266-84025-2-git-send-email-martin@martin.st> --- I think this is what was meant in http://lists.gnu.org/archive/html/gnutls-devel/2012-10/msg00020.html. --- doc/examples/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/examples/Makefile.am b/doc/examples/Makefile.am index 6f42a1f..a42b449 100644 --- a/doc/examples/Makefile.am +++ b/doc/examples/Makefile.am @@ -42,6 +42,7 @@ CXX_LDADD = ../../lib/libgnutlsxx.la \ noinst_PROGRAMS = ex-client-resume ex-client-dtls noinst_PROGRAMS += ex-cert-select ex-client-x509 +noinst_PROGRAMS += ex-serv-dtls if ENABLE_CXX ex_cxx_SOURCES = ex-cxx.cpp @@ -79,4 +80,4 @@ endif libexamples_la_SOURCES = examples.h ex-alert.c ex-pkcs12.c \ ex-session-info.c ex-x509-info.c ex-verify.c \ tcp.c udp.c ex-pkcs11-list.c verify.c ex-verify-ssh.c \ - ex-serv-dtls.c print-ciphersuites.c + print-ciphersuites.c -- 1.7.9.4 From martin at martin.st Mon Oct 29 14:44:25 2012 From: martin at martin.st (Martin Storsjo) Date: Mon, 29 Oct 2012 15:44:25 +0200 Subject: [PATCH 1/2] examples: Make sure the timeout parameter to select is valid Message-ID: <1351518266-84025-1-git-send-email-martin@martin.st> This makes the example work properly on Mac OS X (tested on 10.8). --- doc/examples/ex-serv-dtls.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/examples/ex-serv-dtls.c b/doc/examples/ex-serv-dtls.c index adcc7eb..04cc26b 100644 --- a/doc/examples/ex-serv-dtls.c +++ b/doc/examples/ex-serv-dtls.c @@ -296,6 +296,12 @@ pull_timeout_func (gnutls_transport_ptr_t ptr, unsigned int ms) tv.tv_sec = 0; tv.tv_usec = ms * 1000; + while(tv.tv_usec >= 1000000) + { + tv.tv_usec -= 1000000; + tv.tv_sec++; + } + ret = select (priv->fd + 1, &rfds, NULL, NULL, &tv); if (ret <= 0) -- 1.7.9.4 From nmav at gnutls.org Tue Oct 30 01:21:57 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 30 Oct 2012 01:21:57 +0100 Subject: [PATCH 1/2] examples: Make sure the timeout parameter to select is valid In-Reply-To: <1351518266-84025-1-git-send-email-martin@martin.st> References: <1351518266-84025-1-git-send-email-martin@martin.st> Message-ID: <508F1DA5.1050307@gnutls.org> On 10/29/2012 02:44 PM, Martin Storsjo wrote: > This makes the example work properly on Mac OS X (tested on 10.8). > --- > doc/examples/ex-serv-dtls.c | 6 ++++++ > 1 file changed, 6 insertions(+) > --- > I think this is what was meant in > http://lists.gnu.org/archive/html/gnutls-devel/2012-10/msg00020.html. > --- > doc/examples/Makefile.am | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Thank you. Both were applied. regards, Nikos From david.fuhrmann at googlemail.com Tue Oct 30 16:45:00 2012 From: david.fuhrmann at googlemail.com (David Fuhrmann) Date: Tue, 30 Oct 2012 16:45:00 +0100 Subject: Support for trusted_ca_keys extension during TLS handshake Message-ID: Hello, Currently, I am searching for a TLS library that already supports the trusted_ca_keys extension inside the extended client hello message as described here: http://tools.ietf.org/html/rfc6066#page-12 As it is quite difficult to find any information about an implementation for that over google search, I want to ask you if this extension is already (or soon) be supported by GnuTLS? If not, does anybody know another implementation / library which already supports this extension? It would be great if someone can give me some information regarding this topic. Best regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed Oct 31 11:39:26 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 31 Oct 2012 11:39:26 +0100 Subject: Support for trusted_ca_keys extension during TLS handshake In-Reply-To: References: Message-ID: On Tue, Oct 30, 2012 at 4:45 PM, David Fuhrmann wrote: > Hello, > > Currently, I am searching for a TLS library that already supports the > trusted_ca_keys extension inside the extended client hello message as > described here: http://tools.ietf.org/html/rfc6066#page-12 GnuTLS doesn't support this extension. You can check the capabilities of various implementations at: http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations The particular extension that you're looking for isn't listed meaning it may not be implemented by anyone. > As it is quite difficult to find any information about an implementation for > that over google search, I want to ask you if this extension is already (or > soon) be supported by GnuTLS? If not, does anybody know another > implementation / library which already supports this extension? It is not in our plans to implement since it doesn't look particularly useful/interesting. If you submit a patch however it may be included. What is your use case for this extension? regards, Nikos From david.fuhrmann at googlemail.com Wed Oct 31 13:22:53 2012 From: david.fuhrmann at googlemail.com (David Fuhrmann) Date: Wed, 31 Oct 2012 13:22:53 +0100 Subject: Support for trusted_ca_keys extension during TLS handshake In-Reply-To: References: Message-ID: 2012/10/31 Nikos Mavrogiannopoulos > On Tue, Oct 30, 2012 at 4:45 PM, David Fuhrmann > wrote: > > Hello, > > > > Currently, I am searching for a TLS library that already supports the > > trusted_ca_keys extension inside the extended client hello message as > > described here: http://tools.ietf.org/html/rfc6066#page-12 > > GnuTLS doesn't support this extension. You can check the capabilities > of various implementations at: > http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations > > The particular extension that you're looking for isn't listed meaning > it may not be implemented by anyone. > Hi Nikos, Yes, I already found this page. This extension isn't listed on the page, sure, but I thought that this does not necessarily mean that it is not supported by any library. But as far as I could find out, even openssl seems to not support this particular extension. > > > As it is quite difficult to find any information about an implementation > for > > that over google search, I want to ask you if this extension is already > (or > > soon) be supported by GnuTLS? If not, does anybody know another > > implementation / library which already supports this extension? > > It is not in our plans to implement since it doesn't look particularly > useful/interesting. If you submit a patch however it may be included. > What is your use case for this extension? > I have the situation that an embedded system only has a limited and static set of CA certificates installed (at production time). For these CA certificates, it is intended that you can have newer ones with an overlaping validity period. So, the server needs to know which tls certificate he needs to deliver so that the embedded system can verify it with the existing CA certificate. Best regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at martin.st Wed Oct 31 14:44:35 2012 From: martin at martin.st (Martin Storsjo) Date: Wed, 31 Oct 2012 15:44:35 +0200 Subject: [PATCH] server_name: Return the actual required buffer size if the buffer is too small Message-ID: <1351691075-87596-1-git-send-email-martin@martin.st> Since we require space for the null termination, include this in the info returned if the caller provided a too small buffer. Otherwise, if the caller allocated a buffer of exactly the suggested size, it would still be too small. --- lib/ext/server_name.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/ext/server_name.c b/lib/ext/server_name.c index ad449ad..de5fbe5 100644 --- a/lib/ext/server_name.c +++ b/lib/ext/server_name.c @@ -312,27 +312,27 @@ gnutls_server_name_get (gnutls_session_t session, void *data, if (*data_length > /* greater since we need one extra byte for the null */ priv->server_names[indx].name_length) { *data_length = priv->server_names[indx].name_length; memcpy (data, priv->server_names[indx].name, *data_length); if (*type == GNUTLS_NAME_DNS) /* null terminate */ _data[(*data_length)] = 0; } else { - *data_length = priv->server_names[indx].name_length; + *data_length = priv->server_names[indx].name_length + 1; return GNUTLS_E_SHORT_MEMORY_BUFFER; } return 0; } /** * gnutls_server_name_set: * @session: is a #gnutls_session_t structure. * @type: specifies the indicator type * @name: is a string that contains the server name. * @name_length: holds the length of name * -- 1.7.9.4 From martin at martin.st Wed Oct 31 14:45:15 2012 From: martin at martin.st (Martin Storsjo) Date: Wed, 31 Oct 2012 15:45:15 +0200 Subject: [PATCH] server_name: Store the actual number of server names Message-ID: <1351691115-87745-1-git-send-email-martin@martin.st> Earlier, if the number of set server names exceeded the maximum, the server_names field wasn't bounded to the maximum, which could lead to reading out of bounds in _gnutls_server_name_send_params. --- lib/ext/server_name.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/ext/server_name.c b/lib/ext/server_name.c index 005d80b..ad449ad 100644 --- a/lib/ext/server_name.c +++ b/lib/ext/server_name.c @@ -391,21 +391,21 @@ gnutls_server_name_set (gnutls_session_t session, server_names = priv->server_names_size + 1; if (server_names > MAX_SERVER_NAME_EXTENSIONS) server_names = MAX_SERVER_NAME_EXTENSIONS; priv->server_names[server_names - 1].type = type; memcpy (priv->server_names[server_names - 1].name, name, name_length); priv->server_names[server_names - 1].name_length = name_length; - priv->server_names_size++; + priv->server_names_size = server_names; if (set != 0) _gnutls_ext_set_session_data (session, GNUTLS_EXTENSION_SERVER_NAME, epriv); return 0; } static void _gnutls_server_name_deinit_data (extension_priv_data_t priv) -- 1.7.9.4 From martin at martin.st Wed Oct 31 14:46:23 2012 From: martin at martin.st (Martin Storsjo) Date: Wed, 31 Oct 2012 15:46:23 +0200 Subject: [PATCH 2/2] Support SRTP profile negotiation in the client and server tools In-Reply-To: <1351691183-88153-1-git-send-email-martin@martin.st> References: <1351691183-88153-1-git-send-email-martin@martin.st> Message-ID: <1351691183-88153-2-git-send-email-martin@martin.st> The cli/serv-args files haven't been regenerated in the patch, to avoid the extra stray changes due to differing autogen versions. --- doc/Makefile.am | 4 ++++ lib/libgnutls.map | 2 ++ src/cli-args.def | 7 +++++++ src/cli.c | 3 +++ src/common.c | 9 ++++++++- src/serv-args.def | 7 +++++++ src/serv.c | 3 +++ 7 files changed, 34 insertions(+), 1 deletion(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index 7f4a8a6..0460ffe 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1615,6 +1615,10 @@ FUNCS += functions/gnutls_srp_set_server_credentials_function FUNCS += functions/gnutls_srp_set_server_credentials_function.short FUNCS += functions/gnutls_srp_verifier FUNCS += functions/gnutls_srp_verifier.short +FUNCS += functions/gnutls_srtp_get_selected_profile +FUNCS += functions/gnutls_srtp_get_selected_profile.short +FUNCS += functions/gnutls_srtp_set_profiles +FUNCS += functions/gnutls_srtp_set_profiles.short FUNCS += functions/gnutls_store_commitment FUNCS += functions/gnutls_store_commitment.short FUNCS += functions/gnutls_store_pubkey diff --git a/lib/libgnutls.map b/lib/libgnutls.map index 751e49b..cf03d67 100644 --- a/lib/libgnutls.map +++ b/lib/libgnutls.map @@ -354,6 +354,8 @@ GNUTLS_1_4 gnutls_srp_set_server_credentials_file; gnutls_srp_set_server_credentials_function; gnutls_srp_verifier; + gnutls_srtp_get_selected_profile; + gnutls_srtp_set_profiles; gnutls_strdup; gnutls_strerror; gnutls_strerror_name; diff --git a/src/cli-args.def b/src/cli-args.def index 85952d7..8fafbf4 100644 --- a/src/cli-args.def +++ b/src/cli-args.def @@ -113,6 +113,13 @@ flag = { }; flag = { + name = srtp_profiles; + arg-type = string; + descrip = "Offer SRTP profiles"; + doc = ""; +}; + +flag = { name = crlf; descrip = "Send CR LF instead of LF"; doc = ""; diff --git a/src/cli.c b/src/cli.c index 2cf50d4..01193e5 100644 --- a/src/cli.c +++ b/src/cli.c @@ -673,6 +673,9 @@ init_tls_session (const char *hostname) if (HAVE_OPT(HEARTBEAT)) gnutls_heartbeat_enable (session, GNUTLS_HB_PEER_ALLOWED_TO_SEND); + if (HAVE_OPT(SRTP_PROFILES)) + gnutls_srtp_set_profiles (session, OPT_ARG(SRTP_PROFILES)); + return session; } diff --git a/src/common.c b/src/common.c index 9ef83b6..5b640d6 100644 --- a/src/common.c +++ b/src/common.c @@ -594,6 +594,9 @@ print_info (gnutls_session_t session, int verbose, int print_cert) gnutls_kx_algorithm_t kx; unsigned char session_id[33]; size_t session_id_size = sizeof (session_id); + char srtp_profile[30]; + size_t srtp_profile_size = sizeof (srtp_profile); + int rc; /* print session ID */ gnutls_session_get_id (session, session_id, &session_id_size); @@ -689,10 +692,14 @@ print_info (gnutls_session_t session, int verbose, int print_cert) (gnutls_compression_get (session))); printf ("- Compression: %s\n", tmp); + rc = gnutls_srtp_get_selected_profile (session, srtp_profile, + &srtp_profile_size); + if (rc == 0) + printf ("- SRTP profile: %s\n", srtp_profile); + if (verbose) { gnutls_datum_t cb; - int rc; rc = gnutls_session_channel_binding (session, GNUTLS_CB_TLS_UNIQUE, &cb); diff --git a/src/serv-args.def b/src/serv-args.def index df196ba..2132ca8 100644 --- a/src/serv-args.def +++ b/src/serv-args.def @@ -62,6 +62,13 @@ flag = { }; flag = { + name = srtp_profiles; + arg-type = string; + descrip = "Offer SRTP profiles"; + doc = ""; +}; + +flag = { name = disable-client-cert; value = a; descrip = "Do not request a client certificate"; diff --git a/src/serv.c b/src/serv.c index 6be7a6d..b64b76d 100644 --- a/src/serv.c +++ b/src/serv.c @@ -393,6 +393,9 @@ gnutls_session_t initialize_session (int dtls) if (HAVE_OPT (HEARTBEAT)) gnutls_heartbeat_enable(session, GNUTLS_HB_PEER_ALLOWED_TO_SEND); + if (HAVE_OPT (SRTP_PROFILES)) + gnutls_srtp_set_profiles (session, OPT_ARG(SRTP_PROFILES)); + return session; } -- 1.7.9.4 From martin at martin.st Wed Oct 31 14:46:22 2012 From: martin at martin.st (Martin Storsjo) Date: Wed, 31 Oct 2012 15:46:22 +0200 Subject: [PATCH 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) Message-ID: <1351691183-88153-1-git-send-email-martin@martin.st> The code is heavily modelled on the server_name extension implementation. Open questions: - Would it be necessary to add an accessor function for quering the offered profiles that have been set? - The profile name strings match the ones used in OpenSSL, but compared with the RFC, they lack a "HMAC_" before "SHA1". Is this ok? - Is it ok to have both the setter and getter functions use strings? The corresponding APIs in OpenSSL set the profiles based on a string, but expose the selected profile via a struct. --- doc/protocol/rfc5764.txt | 1459 +++++++++++++++++++++++++++++++++++++++ lib/ext/Makefile.am | 2 +- lib/ext/srtp.c | 415 +++++++++++ lib/ext/srtp.h | 38 + lib/gnutls_extensions.c | 5 + lib/gnutls_int.h | 1 + lib/includes/gnutls/gnutls.h.in | 6 + 7 files changed, 1925 insertions(+), 1 deletion(-) create mode 100644 doc/protocol/rfc5764.txt create mode 100644 lib/ext/srtp.c create mode 100644 lib/ext/srtp.h diff --git a/doc/protocol/rfc5764.txt b/doc/protocol/rfc5764.txt new file mode 100644 index 0000000..6633f00 --- /dev/null +++ b/doc/protocol/rfc5764.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) D. McGrew +Request for Comments: 5764 Cisco Systems +Category: Standards Track E. Rescorla +ISSN: 2070-1721 RTFM, Inc. + May 2010 + + + Datagram Transport Layer Security (DTLS) Extension to Establish Keys + for the Secure Real-time Transport Protocol (SRTP) + +Abstract + + This document describes a Datagram Transport Layer Security (DTLS) + extension to establish keys for Secure RTP (SRTP) and Secure RTP + Control Protocol (SRTCP) flows. DTLS keying happens on the media + path, independent of any out-of-band signalling channel present. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5764. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +McGrew & Rescorla Standards Track [Page 1] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 + 3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4 + 4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5 + 4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5 + 4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7 + 4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8 + 4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12 + 5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13 + 5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13 + 5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13 + 5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13 + 5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16 + 6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17 + 7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17 + 7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18 + 7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18 + 7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19 + 8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23 + Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24 + + + + + +McGrew & Rescorla Standards Track [Page 2] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +1. Introduction + + The Secure RTP (SRTP) profile [RFC3711] can provide confidentiality, + message authentication, and replay protection to RTP data and RTP + Control (RTCP) traffic. SRTP does not provide key management + functionality, but instead depends on external key management to + exchange secret master keys, and to negotiate the algorithms and + parameters for use with those keys. + + Datagram Transport Layer Security (DTLS) [RFC4347] is a channel + security protocol that offers integrated key management, parameter + negotiation, and secure data transfer. Because DTLS data transfer + protocol is generic, it is less highly optimized for use with RTP + than is SRTP, which has been specifically tuned for that purpose. + + This document describes DTLS-SRTP, a SRTP extension for DTLS that + combines the performance and encryption flexibility benefits of SRTP + with the flexibility and convenience of DTLS-integrated key and + association management. DTLS-SRTP can be viewed in two equivalent + ways: as a new key management method for SRTP, and a new RTP-specific + data format for DTLS. + + The key points of DTLS-SRTP are that: + + o application data is protected using SRTP, + + o the DTLS handshake is used to establish keying material, + algorithms, and parameters for SRTP, + + o a DTLS extension is used to negotiate SRTP algorithms, and + + o other DTLS record-layer content types are protected using the + ordinary DTLS record format. + + The remainder of this memo is structured as follows. Section 2 + describes conventions used to indicate normative requirements. + Section 3 provides an overview of DTLS-SRTP operation. Section 4 + specifies the DTLS extensions, while Section 5 discusses how RTP and + RTCP are transported over a DTLS-SRTP channel. Section 6 describes + use with multi-party sessions. Section 7 and Section 9 describe + Security and IANA considerations. + +2. Conventions Used In This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + +McGrew & Rescorla Standards Track [Page 3] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +3. Overview of DTLS-SRTP Operation + + DTLS-SRTP is defined for point-to-point media sessions, in which + there are exactly two participants. Each DTLS-SRTP session contains + a single DTLS association (called a "connection" in TLS jargon), and + either two SRTP contexts (if media traffic is flowing in both + directions on the same host/port quartet) or one SRTP context (if + media traffic is only flowing in one direction). All SRTP traffic + flowing over that pair in a given direction uses a single SRTP + context. A single DTLS-SRTP session only protects data carried over + a single UDP source and destination port pair. + + The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP + flow the peers do a DTLS handshake on the same source and destination + port pair to establish a DTLS association. Which side is the DTLS + client and which side is the DTLS server must be established via some + out-of-band mechanism such as SDP. The keying material from that + handshake is fed into the SRTP stack. Once that association is + established, RTP packets are protected (becoming SRTP) using that + keying material. + + RTP and RTCP traffic is usually sent on two separate UDP ports. When + symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions + are needed, one for the RTP port, one for the RTCP port. When RTP + flows are not symmetric, four unidirectional DTLS-SRTP sessions are + needed (for inbound and outbound RTP, and inbound and outbound RTCP). + + Symmetric RTP [RFC4961] is the case in which there are two RTP + sessions that have their source and destination ports and addresses + reversed, in a manner similar to the way that a TCP connection uses + its ports. Each participant has an inbound RTP session and an + outbound RTP session. When symmetric RTP is used, a single DTLS-SRTP + session can protect both of the RTP sessions. It is RECOMMENDED that + symmetric RTP be used with DTLS-SRTP. + + RTP and RTCP traffic MAY be multiplexed on a single UDP port + [RFC5761]. In this case, both RTP and RTCP packets may be sent over + the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions + needed. This improves the cryptographic performance of DTLS, but may + cause problems when RTCP and RTP are subject to different network + treatment (e.g., for bandwidth reservation or scheduling reasons). + + Between a single pair of participants, there may be multiple media + sessions. There MUST be a separate DTLS-SRTP session for each + distinct pair of source and destination ports used by a media session + (though the sessions can share a single DTLS session and hence + amortize the initial public key handshake!). + + + + +McGrew & Rescorla Standards Track [Page 4] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + A DTLS-SRTP session may be indicated by an external signaling + protocol like SIP. When the signaling exchange is integrity- + protected (e.g., when SIP Identity protection via digital signatures + is used), DTLS-SRTP can leverage this integrity guarantee to provide + complete security of the media stream. A description of how to + indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to + authenticate the endpoints using fingerprints can be found in + [RFC5763]. + + In a naive implementation, when there are multiple media sessions, + there is a new DTLS session establishment (complete with public key + cryptography) for each media channel. For example, a videophone may + be sending both an audio stream and a video stream, each of which + would use a separate DTLS session establishment exchange, which would + proceed in parallel. As an optimization, the DTLS-SRTP + implementation SHOULD use the following strategy: a single DTLS + association is established, and all other DTLS associations wait + until that connection is established before proceeding with their + handshakes. This strategy allows the later sessions to use DTLS + session resumption, which allows the amortization of the expensive + public key cryptography operations over multiple DTLS handshakes. + + The SRTP keys used to protect packets originated by the client are + distinct from the SRTP keys used to protect packets originated by the + server. All of the RTP sources originating on the client for the + same channel use the same SRTP keys, and similarly, all of the RTP + sources originating on the server for the same channel use the same + SRTP keys. The SRTP implementation MUST ensure that all of the + synchronization source (SSRC) values for all of the RTP sources + originating from the same device over the same channel are distinct, + in order to avoid the "two-time pad" problem (as described in Section + 9.1 of RFC 3711). Note that this is not an issue for separate media + streams (on different host/port quartets) that use independent keying + material even if an SSRC collision occurs. + +4. DTLS Extensions for SRTP Key Establishment + +4.1. The use_srtp Extension + + In order to negotiate the use of SRTP data protection, clients + include an extension of type "use_srtp" in the DTLS extended client + hello. This extension MUST only be used when the data being + transported is RTP or RTCP [RFC3550]. The "extension_data" field of + this extension contains the list of acceptable SRTP protection + profiles, as indicated below. + + + + + + +McGrew & Rescorla Standards Track [Page 5] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Servers that receive an extended hello containing a "use_srtp" + extension can agree to use SRTP by including an extension of type + "use_srtp", with the chosen protection profile in the extended server + hello. This process is shown below. + + Client Server + + ClientHello + use_srtp --------> + ServerHello + use_srtp + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + SRTP packets <-------> SRTP packets + + Note that '*' indicates messages that are not always sent in DTLS. + The CertificateRequest, client and server Certificates, and + CertificateVerify will be sent in DTLS-SRTP. + + Once the "use_srtp" extension is negotiated, the RTP or RTCP + application data is protected solely using SRTP. Application data is + never sent in DTLS record-layer "application_data" packets. Rather, + complete RTP or RTCP packets are passed to the DTLS stack, which + passes them to the SRTP stack, which protects them appropriately. + Note that if RTP/RTCP multiplexing [RFC5761] is in use, this means + that RTP and RTCP packets may both be passed to the DTLS stack. + Because the DTLS layer does not process the packets, it does not need + to distinguish them. The SRTP stack can use the procedures of + [RFC5761] to distinguish RTP from RTCP. + + When the "use_srtp" extension is in effect, implementations must not + place more than one application data "record" per datagram. (This is + only meaningful from the perspective of DTLS because SRTP is + inherently oriented towards one payload per packet, but this is + stated purely for clarification.) + + Data other than RTP/RTCP (i.e., TLS control messages) MUST use + ordinary DTLS framing and MUST be placed in separate datagrams from + SRTP data. + + + + + +McGrew & Rescorla Standards Track [Page 6] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + A DTLS-SRTP handshake establishes one or more SRTP crypto contexts; + however, they all have the same SRTP Protection Profile and Master + Key Identifier (MKI), if any. MKIs are used solely to distinguish + the keying material and protection profiles between distinct + handshakes, for instance, due to rekeying. When an MKI is + established in a DTLS-SRTP session, it MUST apply for all of the + SSRCs within that session -- though a single endpoint may negotiate + multiple DTLS-SRTP sessions due, for instance, to forking. (Note + that RFC 3711 allows packets within the same session but with + different SSRCs to use MKIs differently; in contrast, DTLS-SRTP + requires that MKIs and the keys that they are associated with have + the same meaning and are uniform across the entire SRTP session.) + +4.1.1. use_srtp Extension Definition + + The client MUST fill the extension_data field of the "use_srtp" + extension with an UseSRTPData value (see Section 9 for the + registration): + + uint8 SRTPProtectionProfile[2]; + + struct { + SRTPProtectionProfiles SRTPProtectionProfiles; + opaque srtp_mki<0..255>; + } UseSRTPData; + + SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>; + + The SRTPProtectionProfiles list indicates the SRTP protection + profiles that the client is willing to support, listed in descending + order of preference. The srtp_mki value contains the SRTP Master Key + Identifier (MKI) value (if any) that the client will use for his SRTP + packets. If this field is of zero length, then no MKI will be used. + + Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>" + indicates a variable-length value with a length between 0 and 255 + (inclusive). Thus, the MKI may be up to 255 bytes long. + + If the server is willing to accept the use_srtp extension, it MUST + respond with its own "use_srtp" extension in the ExtendedServerHello. + The extension_data field MUST contain a UseSRTPData value with a + single SRTPProtectionProfile value that the server has chosen for use + with this connection. The server MUST NOT select a value that the + client has not offered. If there is no shared profile, the server + SHOULD NOT return the use_srtp extension at which point the + connection falls back to the negotiated DTLS cipher suite. If that + is not acceptable, the server SHOULD return an appropriate DTLS + alert. + + + +McGrew & Rescorla Standards Track [Page 7] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +4.1.2. SRTP Protection Profiles + + A DTLS-SRTP SRTP Protection Profile defines the parameters and + options that are in effect for the SRTP processing. This document + defines the following SRTP protection profiles. + + SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01}; + SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02}; + SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05}; + SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06}; + + The following list indicates the SRTP transform parameters for each + protection profile. The parameters cipher_key_length, + cipher_salt_length, auth_key_length, and auth_tag_length express the + number of bits in the values to which they refer. The + maximum_lifetime parameter indicates the maximum number of packets + that can be protected with each single set of keys when the parameter + profile is in use. All of these parameters apply to both RTP and + RTCP, unless the RTCP parameters are separately specified. + + All of the crypto algorithms in these profiles are from [RFC3711]. + + SRTP_AES128_CM_HMAC_SHA1_80 + cipher: AES_128_CM + cipher_key_length: 128 + cipher_salt_length: 112 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 80 + SRTP_AES128_CM_HMAC_SHA1_32 + cipher: AES_128_CM + cipher_key_length: 128 + cipher_salt_length: 112 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 32 + RTCP auth_tag_length: 80 + SRTP_NULL_HMAC_SHA1_80 + cipher: NULL + cipher_key_length: 0 + cipher_salt_length: 0 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 80 + + + + +McGrew & Rescorla Standards Track [Page 8] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + SRTP_NULL_HMAC_SHA1_32 + cipher: NULL + cipher_key_length: 0 + cipher_salt_length: 0 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 32 + RTCP auth_tag_length: 80 + + With all of these SRTP Parameter profiles, the following SRTP options + are in effect: + + o The TLS PseudoRandom Function (PRF) is used to generate keys to + feed into the SRTP Key Derivation Function (KDF). When DTLS 1.2 + [DTLS1.2] is in use, the PRF is the one associated with the cipher + suite. Note that this specification is compatible with DTLS 1.0 + or DTLS 1.2 + + o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are + not re-derived based on the SRTP sequence number. + + o The key derivation procedures from Section 4.3 with the AES-CM PRF + from RFC 3711 are used. + + o For all other parameters (in particular, SRTP replay window size + and FEC order), the default values are used. + + If values other than the defaults for these parameters are required, + they can be enabled by writing a separate specification specifying + SDP syntax to signal them. + + Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection + Profiles between the DTLS-SRTP session that protects an RTP flow and + the DTLS-SRTP session that protects the associated RTCP flow (in + those cases in which the RTP and RTCP are not multiplexed over a + common port). In particular, identical ciphers SHOULD be used. + + New SRTPProtectionProfile values must be defined according to the + "Specification Required" policy as defined by RFC 5226 [RFC5226]. + See Section 9 for IANA Considerations. + +4.1.3. srtp_mki value + + The srtp_mki value MAY be used to indicate the capability and desire + to use the SRTP Master Key Identifier (MKI) field in the SRTP and + SRTCP packets. The MKI field indicates to an SRTP receiver which key + was used to protect the packet that contains that field. The + + + +McGrew & Rescorla Standards Track [Page 9] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + srtp_mki field contains the value of the SRTP MKI which is associated + with the SRTP master keys derived from this handshake. Each SRTP + session MUST have exactly one master key that is used to protect + packets at any given time. The client MUST choose the MKI value so + that it is distinct from the last MKI value that was used, and it + SHOULD make these values unique for the duration of the TLS session. + + Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, + the server MUST either (assuming it accepts the extension at all): + + 1. include a matching "srtp_mki" value in its "use_srtp" extension + to indicate that it will make use of the MKI, or + 2. return an empty "srtp_mki" value to indicate that it cannot make + use of the MKI. + + If the client detects a nonzero-length MKI in the server's response + that is different than the one the client offered, then the client + MUST abort the handshake and SHOULD send an invalid_parameter alert. + If the client and server agree on an MKI, all SRTP packets protected + under the new security parameters MUST contain that MKI. + + Note that any given DTLS-SRTP session only has a single active MKI + (if any). Thus, at any given time, a set of endpoints will generally + only be using one MKI (the major exception is during rehandshakes). + +4.2. Key Derivation + + When SRTP mode is in effect, different keys are used for ordinary + DTLS record protection and SRTP packet protection. These keys are + generated using a TLS exporter [RFC5705] to generate + + 2 * (SRTPSecurityParams.master_key_len + + SRTPSecurityParams.master_salt_len) bytes of data + + which are assigned as shown below. The per-association context value + is empty. + + client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; + server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; + client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; + server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; + + The exporter label for this usage is "EXTRACTOR-dtls_srtp". (The + "EXTRACTOR" prefix is for historical compatibility.) + + The four keying material values (the master key and master salt for + each direction) are provided as inputs to the SRTP key derivation + mechanism, as shown in Figure 1 and detailed below. By default, the + + + +McGrew & Rescorla Standards Track [Page 10] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + mechanism defined in Section 4.3 of [RFC3711] is used, unless another + key derivation mechanism is specified as part of an SRTP Protection + Profile. + + The client_write_SRTP_master_key and client_write_SRTP_master_salt + are provided to one invocation of the SRTP key derivation function, + to generate the SRTP keys used to encrypt and authenticate packets + sent by the client. The server MUST only use these keys to decrypt + and to check the authenticity of inbound packets. + + The server_write_SRTP_master_key and server_write_SRTP_master_salt + are provided to one invocation of the SRTP key derivation function, + to generate the SRTP keys used to encrypt and authenticate packets + sent by the server. The client MUST only use these keys to decrypt + and to check the authenticity of inbound packets. + + TLS master + secret label + | | + v v + +---------------+ + | TLS extractor | + +---------------+ + | +------+ SRTP + +-> client_write_SRTP_master_key ----+--->| SRTP |-> client + | | +->| KDF | write + | | | +------+ keys + | | | + +-> server_write_SRTP_master_key -- | | +------+ SRTCP + | \ \--->|SRTCP |-> client + | \ +->| KDF | write + | | | +------+ keys + +-> client_write_SRTP_master_salt ---|-+ + | | + | | +------+ SRTP + | +--->| SRTP |-> server + +-> server_write_SRTP_master_salt -+-|--->| KDF | write + | | +------+ keys + | | + | | +------+ SRTCP + | +--->|SRTCP |-> server + +----->| KDF | write + +------+ keys + + Figure 1: The derivation of the SRTP keys. + + + + + + +McGrew & Rescorla Standards Track [Page 11] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + When both RTCP and RTP use the same source and destination ports, + then both the SRTP and SRTCP keys are needed. Otherwise, there are + two DTLS-SRTP sessions, one of which protects the RTP packets and one + of which protects the RTCP packets; each DTLS-SRTP session protects + the part of an SRTP session that passes over a single source/ + destination transport address pair, as shown in Figure 2, independent + of which SSRCs are used on that pair. When a DTLS-SRTP session is + protecting RTP, the SRTCP keys derived from the DTLS handshake are + not needed and are discarded. When a DTLS-SRTP session is protecting + RTCP, the SRTP keys derived from the DTLS handshake are not needed + and are discarded. + + Client Server + (Sender) (Receiver) + (1) <----- DTLS ------> src/dst = a/b and b/a + ------ SRTP ------> src/dst = a/b, uses client write keys + + (2) <----- DTLS ------> src/dst = c/d and d/c + ------ SRTCP -----> src/dst = c/d, uses client write keys + <----- SRTCP ------ src/dst = d/c, uses server write keys + + Figure 2: A DTLS-SRTP session protecting RTP (1) and another one + protecting RTCP (2), showing the transport addresses and keys used. + +4.3. Key Scope + + Because of the possibility of packet reordering, DTLS-SRTP + implementations SHOULD store multiple SRTP keys sets during a rekey + in order to avoid the need for receivers to drop packets for which + they lack a key. + +4.4. Key Usage Limitations + + The maximum_lifetime parameter in the SRTP protection profile + indicates the maximum number of packets that can be protected with + each single encryption and authentication key. (Note that, since RTP + and RTCP are protected with independent keys, those protocols are + counted separately for the purposes of determining when a key has + reached the end of its lifetime.) Each profile defines its own + limit. When this limit is reached, a new DTLS session SHOULD be used + to establish replacement keys, and SRTP implementations MUST NOT use + the existing keys for the processing of either outbound or inbound + traffic. + + + + + + + + +McGrew & Rescorla Standards Track [Page 12] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +5. Use of RTP and RTCP over a DTLS-SRTP Channel + +5.1. Data Protection + + Once the DTLS handshake has completed, the peers can send RTP or RTCP + over the newly created channel. We describe the transmission process + first followed by the reception process. + + Within each RTP session, SRTP processing MUST NOT take place before + the DTLS handshake completes. + +5.1.1. Transmission + + DTLS and TLS define a number of record content types. In ordinary + TLS/DTLS, all data is protected using the same record encoding and + mechanisms. When the mechanism described in this document is in + effect, this is modified so that data written by upper-level protocol + clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP + rather than the standard TLS record encoding. + + When a user of DTLS wishes to send an RTP packet in SRTP mode, it + delivers it to the DTLS implementation as an ordinary application + data write (e.g., SSL_write()). The DTLS implementation then invokes + the processing described in RFC 3711, Sections 3 and 4. The + resulting SRTP packet is then sent directly on the wire as a single + datagram with no DTLS framing. This provides an encapsulation of the + data that conforms to and interoperates with SRTP. Note that the RTP + sequence number rather than the DTLS sequence number is used for + these packets. + +5.1.2. Reception + + When DTLS-SRTP is used to protect an RTP session, the RTP receiver + needs to demultiplex packets that are arriving on the RTP port. + Arriving packets may be of types RTP, DTLS, or STUN [RFC5389]. If + these are the only types of packets present, the type of a packet can + be determined by looking at its first byte. + + The process for demultiplexing a packet is as follows. The receiver + looks at the first byte of the packet. If the value of this byte is + 0 or 1, then the packet is STUN. If the value is in between 128 and + 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and + RTP are being multiplexed over the same destination port). If the + value is between 20 and 63 (inclusive), the packet is DTLS. This + process is summarized in Figure 3. + + + + + + +McGrew & Rescorla Standards Track [Page 13] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + +----------------+ + | 127 < B < 192 -+--> forward to RTP + | | + packet --> | 19 < B < 64 -+--> forward to DTLS + | | + | B < 2 -+--> forward to STUN + +----------------+ + + Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. + Here the field B denotes the leading byte of the packet. + + If other packet types are to be multiplexed as well, implementors + and/or designers SHOULD ensure that they can be demultiplexed from + these three packet types. + + In some cases, there will be multiple DTLS-SRTP associations for a + given SRTP endpoint. For instance, if Alice makes a call that is SIP + forked to both Bob and Charlie, she will use the same local host/port + pair for both of them, as shown in Figure 4, where XXX and YYY + represent different DTLS-SRTP associations. (The SSRCs shown are the + ones for data flowing to Alice.) + + Bob (192.0.2.1:6666) + / + / + / SSRC=1 + / DTLS-SRTP=XXX + / + v + Alice (192.0.2.0:5555) + ^ + \ + \ SSRC=2 + \ DTLS-SRTP=YYY + \ + \ + Charlie (192.0.2.2:6666) + + Figure 4: RTP sessions with SIP forking. + + Because DTLS operates on the host/port quartet, the DTLS association + will still complete correctly, with the foreign host/port pair being + used, to distinguish the associations. However, in RTP the source + host/port is not used and sessions are identified by the destination + host/port and the SSRC. Thus, some mechanism is needed to determine + which SSRCs correspond to which DTLS associations. The following + method SHOULD be used. + + + + +McGrew & Rescorla Standards Track [Page 14] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + For each local host/port pair, the DTLS-SRTP implementation maintains + a table listing all the SSRCs it knows about and the DTLS-SRTP + associations they correspond to. Initially, this table is empty. + When an SRTP packet is received for a given RTP endpoint (destination + IP/port pair), the following procedure is used: + + 1. If the SSRC is already known for that endpoint, then the + corresponding DTLS-SRTP association and its keying material is + used to decrypt and verify the packet. + 2. If the SSRC is not known, then the receiver tries to decrypt it + with the keying material corresponding to each DTLS-SRTP + association for that endpoint. + 3. If the decryption and verification succeeds (the authentication + tag verifies), then an entry is placed in the table mapping the + SSRC to that association. + 4. If the decryption and verification fails, then the packet is + silently discarded. + 5. When a DTLS-SRTP association is closed (for instance, because the + fork is abandoned), its entries MUST be removed from the mapping + table. + + The average cost of this algorithm for a single SSRC is the + decryption and verification time of a single packet times the number + of valid DTLS-SRTP associations corresponding to a single receiving + port on the host. In practice, this means the number of forks; so in + the case shown in Figure 4, that would be two. This cost is only + incurred once for any given SSRC, since afterwards that SSRC is + placed in the map table and looked up immediately. As with normal + RTP, this algorithm allows new SSRCs to be introduced by the source + at any time. They will automatically be mapped to the correct DTLS + association. + + Note that this algorithm explicitly allows multiple SSRCs to be sent + from the same address/port pair. One way in which this can happen is + an RTP translator. This algorithm will automatically assign the + SSRCs to the correct associations. Note that because the SRTP + packets are cryptographically protected, such a translator must + either share keying material with one endpoint or refrain from + modifying the packets in a way which would cause the integrity check + to fail. This is a general property of SRTP and is not specific to + DTLS-SRTP. + + There are two error cases that should be considered. First, if an + SSRC collision occurs, then only the packets from the first source + will be processed. When the packets from the second source arrive, + the DTLS association with the first source will be used for + decryption and verification, which will fail, and the packet will be + discarded. This is consistent with [RFC3550], which permits the + + + +McGrew & Rescorla Standards Track [Page 15] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + receiver to keep the packets from one source and discard those from + the other. Of course the RFC 3550 SSRC collision detection and + handling procedures MUST also be followed. + + Second, there may be cases where a malfunctioning source is sending + corrupt packets that cannot be decrypted and verified. In this case, + the SSRC will never be entered into the mapping table because the + decryption and verification always fails. Receivers MAY keep records + of unmapped SSRCs that consistently fail decryption and verification + and abandon attempts to process them once they reach some limit. + That limit MUST be large enough to account for the effects of + transmission errors. Entries MUST be pruned from this table when the + relevant SRTP endpoint is deleted (e.g., the call ends) and SHOULD + time out faster than that (we do not offer a hard recommendation but + 10 to 30 seconds seems appropriate) in order to allow for the + possibility that the peer implementation has been corrected. + +5.2. Rehandshake and Rekey + + Rekeying in DTLS is accomplished by performing a new handshake over + the existing DTLS channel. That is, the handshake messages are + protected by the existing DTLS cipher suite. This handshake can be + performed in parallel with data transport, so no interruption of the + data flow is required. Once the handshake is finished, the newly + derived set of keys is used to protect all outbound packets, both + DTLS and SRTP. + + Because of packet reordering, packets protected by the previous set + of keys can appear on the wire after the handshake has completed. To + compensate for this fact, receivers SHOULD maintain both sets of keys + for some time in order to be able to decrypt and verify older + packets. The keys should be maintained for the duration of the + maximum segment lifetime (MSL). + + If an MKI is used, then the receiver should use the corresponding set + of keys to process an incoming packet. If no matching MKI is + present, the packet MUST be rejected. Otherwise, when a packet + arrives after the handshake completed, a receiver SHOULD use the + newly derived set of keys to process that packet unless there is an + MKI. (If the packet was protected with the older set of keys, this + fact will become apparent to the receiver as an authentication + failure will occur.) If the authentication check on the packet fails + and no MKI is being used, then the receiver MAY process the packet + with the older set of keys. If that authentication check indicates + that the packet is valid, the packet should be accepted; otherwise, + the packet MUST be discarded and rejected. + + + + + +McGrew & Rescorla Standards Track [Page 16] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Receivers MAY use the SRTP packet sequence number to aid in the + selection of keys. After a packet has been received and + authenticated with the new key set, any packets with sequence numbers + that are greater will also have been protected with the new key set. + +6. Multi-Party RTP Sessions + + Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only + to protect unicast RTP sessions. This does not preclude its use with + RTP mixers. For example, a conference bridge may use DTLS-SRTP to + secure the communication to and from each of the participants in a + conference. However, because each flow between an endpoint and a + mixer has its own key, the mixer has to decrypt and then reencrypt + the traffic for each recipient. + + A future specification may describe methods for sharing a single key + between multiple DTLS-SRTP associations thus allowing conferencing + systems to avoid the decrypt/reencrypt stage. However, any system in + which the media is modified (e.g., for level balancing or + transcoding) will generally need to be performed on the plaintext and + will certainly break the authentication tag, and therefore will + require a decrypt/reencrypt stage. + +7. Security Considerations + + The use of multiple data protection framings negotiated in the same + handshake creates some complexities, which are discussed here. + +7.1. Security of Negotiation + + One concern here is that attackers might be able to implement a bid- + down attack forcing the peers to use ordinary DTLS rather than SRTP. + However, because the negotiation of this extension is performed in + the DTLS handshake, it is protected by the Finished messages. + Therefore, any bid-down attack is automatically detected, which + reduces this to a denial-of-service attack -- which can be mounted by + any attacker who can control the channel. + +7.2. Framing Confusion + + Because two different framing formats are used, there is concern that + an attacker could convince the receiver to treat an SRTP-framed RTP + packet as a DTLS record (e.g., a handshake message) or vice versa. + This attack is prevented by using different keys for Message + Authentication Code (MAC) verification for each type of data. + Therefore, this type of attack reduces to being able to forge a + packet with a valid MAC, which violates a basic security invariant of + both DTLS and SRTP. + + + +McGrew & Rescorla Standards Track [Page 17] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + As an additional defense against injection into the DTLS handshake + channel, the DTLS record type is included in the MAC. Therefore, an + SRTP record would be treated as an unknown type and ignored. (See + Section 6 of [RFC5246].) + +7.3. Sequence Number Interactions + + As described in Section 5.1.1, the SRTP and DTLS sequence number + spaces are distinct. This means that it is not possible to + unambiguously order a given DTLS control record with respect to an + SRTP packet. In general, this is relevant in two situations: alerts + and rehandshake. + +7.3.1. Alerts + + Because DTLS handshake and change_cipher_spec messages share the same + sequence number space as alerts, they can be ordered correctly. + Because DTLS alerts are inherently unreliable and SHOULD NOT be + generated as a response to data packets, reliable sequencing between + SRTP packets and DTLS alerts is not an important feature. However, + implementations that wish to use DTLS alerts to signal problems with + the SRTP encoding SHOULD simply act on alerts as soon as they are + received and assume that they refer to the temporally contiguous + stream. Such implementations MUST check for alert retransmission and + discard retransmitted alerts to avoid overreacting to replay attacks. + +7.3.2. Renegotiation + + Because the rehandshake transition algorithm specified in Section 5.2 + requires trying multiple sets of keys if no MKI is used, it slightly + weakens the authentication. For instance, if an n-bit MAC is used + and k different sets of keys are present, then the MAC is weakened by + log_2(k) bits to n - log_2(k). In practice, since the number of keys + used will be very small and the MACs in use are typically strong (the + default for SRTP is 80 bits), the decrease in security involved here + is minimal. + + Another concern here is that this algorithm slightly increases the + work factor on the receiver because it needs to attempt multiple + validations. However, again, the number of potential keys will be + very small (and the attacker cannot force it to be larger) and this + technique is already used for rollover counter management, so the + authors do not consider this to be a serious flaw. + + + + + + + + +McGrew & Rescorla Standards Track [Page 18] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +7.4. Decryption Cost + + An attacker can impose computational costs on the receiver by sending + superficially valid SRTP packets that do not decrypt correctly. In + general, encryption algorithms are so fast that this cost is + extremely small compared to the bandwidth consumed. The SSRC-DTLS + mapping algorithm described in Section 5.1.2 gives the attacker a + slight advantage here because he can force the receiver to do more + then one decryption per packet. However, this advantage is modest + because the number of decryptions that the receiver does is limited + by the number of associations he has corresponding to a given + destination host/port, which is typically quite small. For + comparison, a single 1024-bit RSA private key operation (the typical + minimum cost to establish a DTLS-SRTP association) is hundreds of + times as expensive as decrypting an SRTP packet. + + Implementations can detect this form of attack by keeping track of + the number of SRTP packets that are observed with unknown SSRCs and + that fail the authentication tag check. If under such attack, + implementations SHOULD prioritize decryption and verification of + packets that either have known SSRCs or come from source addresses + that match those of peers with which it has DTLS-SRTP associations. + +8. Session Description for RTP/SAVP over DTLS + + This specification defines new tokens to describe the protocol used + in SDP media descriptions ("m=" lines and their associated + parameters). The new values defined for the proto field are: + + o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over + DTLS with the Datagram Congestion Control Protocol (DCCP), then + the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF + respectively. + + o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with + UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF + respectively. + + The "fmt" parameter SHALL be as defined for RTP/SAVP. + + See [RFC5763] for how to use offer/answer with DTLS-SRTP. + + This document does not specify how to protect RTP data transported + over TCP. Potential approaches include carrying the RTP over TLS + over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that + in this document over TCP, either via TLS or DTLS, with DTLS being + used for consistency between reliable and unreliable transports. In + + + + +McGrew & Rescorla Standards Track [Page 19] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + the latter case, it would be necessary to profile DTLS so that + fragmentation and retransmissions no longer occurred. In either + case, a new document would be required. + +9. IANA Considerations + + This document adds a new extension for DTLS, in accordance with + [RFC5246]: + enum { use_srtp (14) } ExtensionType; + + This extension MUST only be used with DTLS, and not with TLS + [RFC4572], which specifies that TLS can be used over TCP but does not + address TCP for RTP/SAVP. + + Section 4.1.2 requires that all SRTPProtectionProfile values be + defined by RFC 5226 "Specification Required". IANA has created a + DTLS SRTPProtectionProfile registry initially populated with values + from Section 4.1.2 of this document. Future values MUST be allocated + via the "Specification Required" profile of [RFC5226]. + + This specification updates the "Session Description Protocol (SDP) + Parameters" registry as defined in Section 8.2.2 of [RFC4566]. + Specifically, it adds the following values to the table for the + "proto" field. + + Type SDP Name Reference + ---- ------------------ --------- + proto UDP/TLS/RTP/SAVP [RFC5764] + proto DCCP/TLS/RTP/SAVP [RFC5764] + + proto UDP/TLS/RTP/SAVPF [RFC5764] + proto DCCP/TLS/RTP/SAVPF [RFC5764] + + IANA has registered the "EXTRACTOR-dtls_srtp" value in the TLS + Extractor Label Registry to correspond to this specification. + +10. Acknowledgments + + Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen, + Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing, + and Ben Campbell for input, discussions, and guidance. Pasi Eronen + provided Figure 1. + + + + + + + + + +McGrew & Rescorla Standards Track [Page 20] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., + and K. Norrman, "The Secure Real-time Transport + Protocol (SRTP)", RFC 3711, March 2004. + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security", RFC 4347, April 2006. + + [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol + (RTCP)", BCP 131, RFC 4961, July 2007. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5705] Rescorla, E., "Keying Material Exporters for + Transport Layer Security (TLS)", RFC 5705, + March 2010. + + [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP + Data and Control Packets on a Single Port", + RFC 5761, April 2010. + +11.2. Informative References + + [DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security version 1.2", Work in Progress, + October 2009. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, July 2006. + + [RFC4572] Lennox, J., "Connection-Oriented Media Transport + over the Transport Layer Security (TLS) Protocol in + the Session Description Protocol (SDP)", RFC 4572, + July 2006. + + + + + +McGrew & Rescorla Standards Track [Page 21] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile + for Real-time Transport Control Protocol (RTCP)- + Based Feedback (RTP/SAVPF)", RFC 5124, + February 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 5226, May 2008. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", + RFC 5389, October 2008. + + [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, + "Framework for Establishing a Secure Real-time + Transport Protocol (SRTP) Security Context Using + Datagram Transport Layer Security (DTLS)", RFC 5763, + May 2010. + + [SRTP-NOT-MAND] Perkins, C. and M. Westerlund, "Why RTP Does Not + Mandate a Single Security Mechanism", Work in + Progress, January 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGrew & Rescorla Standards Track [Page 22] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +Appendix A. Overview of DTLS + + This section provides a brief overview of Datagram TLS (DTLS) for + those who are not familiar with it. DTLS is a channel security + protocol based on the well-known Transport Layer Security (TLS) + [RFC5246] protocol. Where TLS depends on a reliable transport + channel (typically TCP), DTLS has been adapted to support unreliable + transports such as UDP. Otherwise, DTLS is nearly identical to TLS + and generally supports the same cryptographic mechanisms. + + Each DTLS association begins with a handshake exchange (shown below) + during which the peers authenticate each other and negotiate + algorithms, modes, and other parameters and establish shared keying + material, as shown below. In order to support unreliable transport, + each side maintains retransmission timers to provide reliable + delivery of these messages. Once the handshake is completed, + encrypted data may be sent. + + Client Server + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + '*' indicates messages that are not always sent. + + Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]). + + Application data is protected by being sent as a series of DTLS + "records". These records are independent and can be processed + correctly even in the face of loss or reordering. In DTLS-SRTP, this + record protocol is replaced with SRTP [RFC3711] + + + + + + + + +McGrew & Rescorla Standards Track [Page 23] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +Appendix B. Performance of Multiple DTLS Handshakes + + Standard practice for security protocols such as TLS, DTLS, and SSH, + which do inline key management, is to create a separate security + association for each underlying network channel (TCP connection, UDP + host/port quartet, etc.). This has dual advantages of simplicity and + independence of the security contexts for each channel. + + Three concerns have been raised about the overhead of this strategy + in the context of RTP security. The first concern is the additional + performance overhead of doing a separate public key operation for + each channel. The conventional procedure here (used in TLS and DTLS) + is to establish a master context that can then be used to derive + fresh traffic keys for new associations. In TLS/DTLS, this is called + "session resumption" and can be transparently negotiated between the + peers. + + The second concern is network bandwidth overhead for the + establishment of subsequent connections and for rehandshake (for + rekeying) for existing connections. In particular, there is a + concern that the channels will have very narrow capacity requirements + allocated entirely to media that will be overflowed by the + rehandshake. Measurements of the size of the rehandshake (with + resumption) in TLS indicate that it is about 300-400 bytes if a full + selection of cipher suites is offered. (The size of a full handshake + is approximately 1-2 kilobytes larger because of the certificate and + keying material exchange.) + + The third concern is the additional round-trips associated with + establishing the second, third, ... channels. In TLS/DTLS, these can + all be done in parallel, but in order to take advantage of session + resumption they should be done after the first channel is + established. For two channels, this provides a ladder diagram + something like this (parenthetical numbers are media channel numbers) + + + + + + + + + + + + + + + + + +McGrew & Rescorla Standards Track [Page 24] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Alice Bob + ------------------------------------------- + <- ClientHello (1) + ServerHello (1) -> + Certificate (1) + ServerHelloDone (1) + <- ClientKeyExchange (1) + ChangeCipherSpec (1) + Finished (1) + ChangeCipherSpec (1)-> + Finished (1)-> + <--- Channel 1 ready + + <- ClientHello (2) + ServerHello (2) -> + ChangeCipherSpec(2)-> + Finished(2) -> + <- ChangeCipherSpec (2) + Finished (2) + <--- Channel 2 ready + + Figure 6: Parallel DTLS-SRTP negotiations. + + So, there is an additional 1 RTT (round-trip time) after Channel 1 is + ready before Channel 2 is ready. If the peers are potentially + willing to forego resumption, they can interlace the handshakes, like + so: + + + + + + + + + + + + + + + + + + + + + + + + +McGrew & Rescorla Standards Track [Page 25] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Alice Bob + ------------------------------------------- + <- ClientHello (1) + ServerHello (1) -> + Certificate (1) + ServerHelloDone (1) + <- ClientKeyExchange (1) + ChangeCipherSpec (1) + Finished (1) + <- ClientHello (2) + ChangeCipherSpec (1)-> + Finished (1)-> + <--- Channel 1 ready + ServerHello (2) -> + ChangeCipherSpec(2)-> + Finished(2) -> + <- ChangeCipherSpec (2) + Finished (2) + <--- Channel 2 ready + + Figure 7: Interlaced DTLS-SRTP negotiations. + + In this case, the channels are ready contemporaneously, but if a + message in handshake (1) is lost, then handshake (2) requires either + a full rehandshake or that Alice be clever and queue the resumption + attempt until the first handshake completes. Note that just dropping + the packet works as well, since Bob will retransmit. + +Authors' Addresses + + David McGrew + Cisco Systems + 510 McCarthy Blvd. + Milpitas, CA 95305 + USA + + EMail: mcgrew at cisco.com + + + Eric Rescorla + RTFM, Inc. + 2064 Edgewood Drive + Palo Alto, CA 94303 + USA + + EMail: ekr at rtfm.com + + + + + +McGrew & Rescorla Standards Track [Page 26] + diff --git a/lib/ext/Makefile.am b/lib/ext/Makefile.am index ca6628e..0d97132 100644 --- a/lib/ext/Makefile.am +++ b/lib/ext/Makefile.am @@ -39,5 +39,5 @@ libgnutls_ext_la_SOURCES = max_record.c cert_type.c \ max_record.h cert_type.h server_name.h srp.h \ session_ticket.h signature.h safe_renegotiation.h \ session_ticket.c srp.c ecc.c ecc.h heartbeat.c heartbeat.h \ - status_request.h status_request.c + status_request.h status_request.c srtp.c srtp.h diff --git a/lib/ext/srtp.c b/lib/ext/srtp.c new file mode 100644 index 0000000..7b582ba --- /dev/null +++ b/lib/ext/srtp.c @@ -0,0 +1,415 @@ +/* + * Copyright (C) 2012 Free Software Foundation, Inc. + * + * Author: Martin Storsjo + * + * This file is part of GnuTLS. + * + * The GnuTLS is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 3 of + * the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with this program. If not, see + * + */ + +#include "gnutls_int.h" +#include "gnutls_auth.h" +#include "gnutls_errors.h" +#include "gnutls_num.h" +#include + +static int _gnutls_srtp_recv_params (gnutls_session_t session, + const uint8_t * data, + size_t data_size); +static int _gnutls_srtp_send_params (gnutls_session_t session, + gnutls_buffer_st* extdata); + +static int _gnutls_srtp_unpack (gnutls_buffer_st * ps, + extension_priv_data_t * _priv); +static int _gnutls_srtp_pack (extension_priv_data_t _priv, + gnutls_buffer_st * ps); +static void _gnutls_srtp_deinit_data (extension_priv_data_t priv); + + +extension_entry_st ext_mod_srtp = { + .name = "SRTP", + .type = GNUTLS_EXTENSION_SRTP, + .parse_type = GNUTLS_EXT_APPLICATION, + + .recv_func = _gnutls_srtp_recv_params, + .send_func = _gnutls_srtp_send_params, + .pack_func = _gnutls_srtp_pack, + .unpack_func = _gnutls_srtp_unpack, + .deinit_func = _gnutls_srtp_deinit_data, +}; + +typedef struct +{ + const char *name; + uint16_t id; +} srtp_profile_st; + +static const srtp_profile_st profile_names[] = { + { + "SRTP_AES128_CM_SHA1_80", + 0x0001, + }, + { + "SRTP_AES128_CM_SHA1_32", + 0x0002, + }, + { + "SRTP_NULL_SHA1_80", + 0x0005, + }, + { + "SRTP_NULL_SHA1_32", + 0x0006, + }, + { + NULL, + 0 + } +}; + +static uint16_t find_profile (const char *str, const char *end) +{ + const srtp_profile_st *prof = profile_names; + int len; + if (end != NULL) + { + len = end - str; + } + else + { + len = strlen (str); + } + + while (prof->name != NULL) + { + if (strlen (prof->name) == len && !strncmp (str, prof->name, len)) + { + return prof->id; + } + prof++; + } + return 0; +} + +static int +_gnutls_srtp_recv_params (gnutls_session_t session, + const uint8_t *data, size_t _data_size) +{ + int i, j, ret; + const uint8_t *p = data; + int len; + ssize_t data_size = _data_size; + srtp_ext_st *priv; + extension_priv_data_t epriv; + uint16_t profiles[MAX_SRTP_PROFILES]; + unsigned int profiles_size = 0; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + return 0; + + priv = epriv.ptr; + + DECR_LENGTH_RET (data_size, 2, 0); + len = _gnutls_read_uint16 (p); + p += 2; + + while (len > 0) + { + DECR_LENGTH_RET (data_size, 2, 0); + if (profiles_size < MAX_SRTP_PROFILES) + profiles_size++; + profiles[profiles_size - 1] = _gnutls_read_uint16 (p); + p += 2; + len -= 2; + } + + for (i = 0; i < priv->profiles_size && priv->selected_profile == 0; i++) + { + for (j = 0; j < profiles_size; j++) + { + if (priv->profiles[i] == profiles[j]) + { + priv->selected_profile = profiles[j]; + break; + } + } + } + + return 0; +} + +/* returns data_size or a negative number on failure + */ +static int +_gnutls_srtp_send_params (gnutls_session_t session, + gnutls_buffer_st* extdata) +{ + uint16_t len; + unsigned i; + int total_size = 0, ret; + srtp_ext_st *priv; + extension_priv_data_t epriv; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + return 0; + + priv = epriv.ptr; + + if (priv->profiles_size == 0) + return 0; + + if (session->security_parameters.entity == GNUTLS_SERVER) + { + /* Don't send anything if no matching profile was found */ + if (priv->selected_profile == 0) + return 0; + + ret = _gnutls_buffer_append_prefix(extdata, 16, 2); + if (ret < 0) + return gnutls_assert_val(ret); + ret = _gnutls_buffer_append_prefix(extdata, 16, priv->selected_profile); + if (ret < 0) + return gnutls_assert_val(ret); + total_size = 4; + } + else + { + ret = _gnutls_buffer_append_prefix(extdata, 16, 2 * priv->profiles_size); + if (ret < 0) + return gnutls_assert_val(ret); + + for (i = 0; i < priv->profiles_size; i++) + { + ret = _gnutls_buffer_append_prefix(extdata, 16, priv->profiles[i]); + if (ret < 0) + return gnutls_assert_val(ret); + } + total_size = 2 + 2 * priv->profiles_size; + } + + /* use_mki, not supported yet */ + ret = _gnutls_buffer_append_prefix(extdata, 8, 0); + if (ret < 0) + return gnutls_assert_val(ret); + + return total_size + 1; +} + +/** + * gnutls_srtp_get_selected_profile: + * @session: is a #gnutls_session_t structure. + * @profile: will hold the data + * @profile_length: will hold the data length. Must hold the maximum size of + * profile. + * + * This function will allow you to get the negotiated SRTP profile. + * + * If @profile has not enough size to hold the profile + * GNUTLS_E_SHORT_MEMORY_BUFFER is returned, and @profile_length will + * hold the required size. + * + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, + * otherwise a negative error code is returned. + **/ +int +gnutls_srtp_get_selected_profile (gnutls_session_t session, char *profile, + size_t *profile_length) +{ + srtp_ext_st *priv; + int ret, len; + extension_priv_data_t epriv; + const srtp_profile_st *prof = profile_names; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + { + gnutls_assert (); + return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE; + } + + priv = epriv.ptr; + + if (priv->selected_profile == 0) + { + return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE; + } + + while (prof->name != NULL) + { + if (prof->id == priv->selected_profile) + break; + prof++; + } + + if (prof->name == NULL) + { + /* We only ever set profiles that we've matched against the profile + * name list, and we only set selected_profile to one of the profiles + * we've chosen, so this shouldn't happen. */ + gnutls_assert (); + return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE; + } + + len = strlen (prof->name); + + if (*profile_length > len) + { + *profile_length = len; + strcpy (profile, prof->name); + } + else + { + *profile_length = len + 1; /* Requires extra space for the null termination */ + return GNUTLS_E_SHORT_MEMORY_BUFFER; + } + + return 0; +} + +/** + * gnutls_srtp_set_profiles: + * @session: is a #gnutls_session_t structure. + * @profiles: is a string that contains the supported SRTP profiles, + * separated by colons. + * + * This function is to be used by both clients and servers, to declare + * what SRTP profiles they support, to negotiate with the peer. + * + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, + * otherwise a negative error code is returned. + **/ +int +gnutls_srtp_set_profiles (gnutls_session_t session, + const char *profiles) +{ + int server_names, ret; + srtp_ext_st *priv; + extension_priv_data_t epriv; + int set = 0; + const char *col; + uint16_t id; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + { + set = 1; + } + + if (set != 0) + { + priv = gnutls_calloc (1, sizeof (*priv)); + if (priv == NULL) + { + gnutls_assert (); + return GNUTLS_E_MEMORY_ERROR; + } + epriv.ptr = priv; + } + else + priv = epriv.ptr; + + do + { + col = strchr (profiles, ':'); + id = find_profile (profiles, col); + if (id == 0) + { + if (set != 0) + { + gnutls_free (priv); + } + return GNUTLS_E_ILLEGAL_PARAMETER; + } + + if (priv->profiles_size < MAX_SRTP_PROFILES) + { + priv->profiles_size++; + } + priv->profiles[priv->profiles_size - 1] = id; + profiles = col + 1; + } while (col != NULL); + + if (set != 0) + _gnutls_ext_set_session_data (session, GNUTLS_EXTENSION_SRTP, + epriv); + + return 0; +} + +static void +_gnutls_srtp_deinit_data (extension_priv_data_t priv) +{ + gnutls_free (priv.ptr); +} + +static int +_gnutls_srtp_pack (extension_priv_data_t epriv, gnutls_buffer_st * ps) +{ + srtp_ext_st *priv = epriv.ptr; + unsigned int i; + int ret; + + BUFFER_APPEND_NUM (ps, priv->profiles_size); + for (i = 0; i < priv->profiles_size; i++) + { + BUFFER_APPEND_NUM (ps, priv->profiles[i]); + } + BUFFER_APPEND_NUM (ps, priv->selected_profile); + return 0; +} + +static int +_gnutls_srtp_unpack (gnutls_buffer_st * ps, + extension_priv_data_t * _priv) +{ + srtp_ext_st *priv; + unsigned int i; + int ret; + extension_priv_data_t epriv; + + priv = gnutls_calloc (1, sizeof (*priv)); + if (priv == NULL) + { + gnutls_assert (); + return GNUTLS_E_MEMORY_ERROR; + } + + BUFFER_POP_NUM (ps, priv->profiles_size); + for (i = 0; i < priv->profiles_size; i++) + { + BUFFER_POP_NUM (ps, priv->profiles[i]); + } + BUFFER_POP_NUM (ps, priv->selected_profile); + + epriv.ptr = priv; + *_priv = epriv; + + return 0; + +error: + gnutls_free (priv); + return ret; +} diff --git a/lib/ext/srtp.h b/lib/ext/srtp.h new file mode 100644 index 0000000..44d5b87 --- /dev/null +++ b/lib/ext/srtp.h @@ -0,0 +1,38 @@ +/* + * Copyright (C) 2012 Free Software Foundation, Inc. + * + * Author: Martin Storsjo + * + * This file is part of GnuTLS. + * + * The GnuTLS is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 3 of + * the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with this program. If not, see + * + */ +#ifndef EXT_SRTP_H +#define EXT_SRTP_H + +#include + +#define MAX_SRTP_PROFILES 4 + +typedef struct +{ + uint16_t profiles[MAX_SRTP_PROFILES]; + unsigned profiles_size; + uint16_t selected_profile; +} srtp_ext_st; + +extern extension_entry_st ext_mod_srtp; + +#endif diff --git a/lib/gnutls_extensions.c b/lib/gnutls_extensions.c index aab0a67..28a852b 100644 --- a/lib/gnutls_extensions.c +++ b/lib/gnutls_extensions.c @@ -39,6 +39,7 @@ #include #include #include +#include #include @@ -354,6 +355,10 @@ _gnutls_ext_init (void) if (ret != GNUTLS_E_SUCCESS) return ret; + ret = _gnutls_ext_register (&ext_mod_srtp); + if (ret != GNUTLS_E_SUCCESS) + return ret; + return GNUTLS_E_SUCCESS; } diff --git a/lib/gnutls_int.h b/lib/gnutls_int.h index 1f103cb..68a176e 100644 --- a/lib/gnutls_int.h +++ b/lib/gnutls_int.h @@ -261,6 +261,7 @@ typedef enum extensions_t GNUTLS_EXTENSION_SUPPORTED_ECC_PF = 11, GNUTLS_EXTENSION_SRP = 12, GNUTLS_EXTENSION_SIGNATURE_ALGORITHMS = 13, + GNUTLS_EXTENSION_SRTP = 14, GNUTLS_EXTENSION_HEARTBEAT = 15, GNUTLS_EXTENSION_SESSION_TICKET = 35, GNUTLS_EXTENSION_SAFE_RENEGOTIATION = 65281 /* aka: 0xff01 */ diff --git a/lib/includes/gnutls/gnutls.h.in b/lib/includes/gnutls/gnutls.h.in index e60914e..a6db1dd 100644 --- a/lib/includes/gnutls/gnutls.h.in +++ b/lib/includes/gnutls/gnutls.h.in @@ -960,6 +960,12 @@ gnutls_ecc_curve_t gnutls_ecc_curve_get(gnutls_session_t session); int gnutls_session_ticket_enable_server (gnutls_session_t session, const gnutls_datum_t * key); + /* SRTP, RFC 5764 */ + int gnutls_srtp_set_profiles (gnutls_session_t session, + const char *profiles); + int gnutls_srtp_get_selected_profile (gnutls_session_t session, + char *profile, size_t *profile_length); + int gnutls_key_generate (gnutls_datum_t * key, unsigned int key_size); /* if you just want some defaults, use the following. -- 1.7.9.4 From martin at martinpaljak.net Wed Oct 31 16:06:43 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 31 Oct 2012 17:06:43 +0200 Subject: Support for trusted_ca_keys extension during TLS handshake In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 2:22 PM, David Fuhrmann wrote: > I have the situation that an embedded system only has a limited and static > set of CA > certificates installed (at production time). For these CA certificates, it > is intended that you > can have newer ones with an overlaping validity period. So, the server needs > to know > which tls certificate he needs to deliver so that the embedded system can > verify it with > the existing CA certificate. Does this mean that you would have two overlapping CA keys/certificates, with the same name but different validity periods? This sounds like a strange setup to me. Why can't the client system differentiate the (updated) issuer itself, by changing the common name of the new root? Martin From david.fuhrmann at googlemail.com Wed Oct 31 16:50:30 2012 From: david.fuhrmann at googlemail.com (David Fuhrmann) Date: Wed, 31 Oct 2012 16:50:30 +0100 Subject: Support for trusted_ca_keys extension during TLS handshake In-Reply-To: References: Message-ID: <8BC6FA81-F5FA-4564-97E3-1415B228593A@googlemail.com> Am 31.10.2012 um 16:06 schrieb Martin Paljak : > On Wed, Oct 31, 2012 at 2:22 PM, David Fuhrmann > wrote: >> I have the situation that an embedded system only has a limited and static >> set of CA >> certificates installed (at production time). For these CA certificates, it >> is intended that you >> can have newer ones with an overlaping validity period. So, the server needs >> to know >> which tls certificate he needs to deliver so that the embedded system can >> verify it with >> the existing CA certificate. > > Does this mean that you would have two overlapping CA > keys/certificates, with the same name but different validity periods? > > This sounds like a strange setup to me. Why can't the client system > differentiate the (updated) issuer itself, by changing the common name > of the new root? How naming is handled doesn't matter here. The problem is, that the client has (in the simplest case) only one CA / root certificate, and also no internet connection or any possibility to update this root certificate. Now after specified intervals, a new root certificate is created, to have a fresh one to be installed into newer clients. So, every Client has a root certificate, which has a validity of minimum x years. The server has as much TLS certificates as root certificates exist (issued by these root certs over a chain). So as the client want to validate the TLS certificate, and only has one root certificate, the server needs to send the one TLS certificate which is issued by the root which exists in the client. In order to determine the right one, the client shall send the existing root cert over this extension to the server before. Best, David From nmav at gnutls.org Wed Oct 31 18:32:03 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 31 Oct 2012 18:32:03 +0100 Subject: Support for trusted_ca_keys extension during TLS handshake In-Reply-To: <8BC6FA81-F5FA-4564-97E3-1415B228593A@googlemail.com> References: <8BC6FA81-F5FA-4564-97E3-1415B228593A@googlemail.com> Message-ID: On Wed, Oct 31, 2012 at 4:50 PM, David Fuhrmann wrote: >> Does this mean that you would have two overlapping CA >> keys/certificates, with the same name but different validity periods? >> This sounds like a strange setup to me. Why can't the client system >> differentiate the (updated) issuer itself, by changing the common name >> of the new root? > How naming is handled doesn't matter here. > The problem is, that the client has (in the simplest case) only one CA / root certificate, and also no internet > connection or any possibility to update this root certificate. > Now after specified intervals, a new root certificate is created, to have a fresh one to be installed into newer clients. > So, every Client has a root certificate, which has a validity of minimum x years. I don't know whether you can apply it in your case, but why not use the "traditional" PKI there. Have a root CA to sign all other temporal CAs and have all the devices to trust the root one. It sounds more elegant approach than having the server decide which certificate to use based on the connecting client trusted CA. regards, Nikos From nmav at gnutls.org Wed Oct 31 18:36:07 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 31 Oct 2012 18:36:07 +0100 Subject: [PATCH] server_name: Return the actual required buffer size if the buffer is too small In-Reply-To: <1351691075-87596-1-git-send-email-martin@martin.st> References: <1351691075-87596-1-git-send-email-martin@martin.st> Message-ID: <50916187.5040803@gnutls.org> On 10/31/2012 02:44 PM, Martin Storsjo wrote: > Since we require space for the null termination, include this in > the info returned if the caller provided a too small buffer. > Otherwise, if the caller allocated a buffer of exactly the suggested > size, it would still be too small. Thanks, applied! From nmav at gnutls.org Wed Oct 31 18:36:51 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 31 Oct 2012 18:36:51 +0100 Subject: [PATCH] server_name: Store the actual number of server names In-Reply-To: <1351691115-87745-1-git-send-email-martin@martin.st> References: <1351691115-87745-1-git-send-email-martin@martin.st> Message-ID: <509161B3.7030707@gnutls.org> On 10/31/2012 02:45 PM, Martin Storsjo wrote: > Earlier, if the number of set server names exceeded the maximum, > the server_names field wasn't bounded to the maximum, which could > lead to reading out of bounds in _gnutls_server_name_send_params. Applied! From david.fuhrmann at googlemail.com Wed Oct 31 18:40:02 2012 From: david.fuhrmann at googlemail.com (David Fuhrmann) Date: Wed, 31 Oct 2012 18:40:02 +0100 Subject: Support for trusted_ca_keys extension during TLS handshake In-Reply-To: References: <8BC6FA81-F5FA-4564-97E3-1415B228593A@googlemail.com> Message-ID: <87804DA7-FE6A-4F84-B377-7E0C40ECD479@googlemail.com> Am 31.10.2012 um 18:32 schrieb Nikos Mavrogiannopoulos : > On Wed, Oct 31, 2012 at 4:50 PM, David Fuhrmann > wrote: > >>> Does this mean that you would have two overlapping CA >>> keys/certificates, with the same name but different validity periods? >>> This sounds like a strange setup to me. Why can't the client system >>> differentiate the (updated) issuer itself, by changing the common name >>> of the new root? >> How naming is handled doesn't matter here. >> The problem is, that the client has (in the simplest case) only one CA / root certificate, and also no internet >> connection or any possibility to update this root certificate. >> Now after specified intervals, a new root certificate is created, to have a fresh one to be installed into newer clients. >> So, every Client has a root certificate, which has a validity of minimum x years. > > I don't know whether you can apply it in your case, but why not use > the "traditional" PKI there. Have a root CA to sign all other temporal > CAs and have all the devices to trust the root one. It sounds more > elegant approach than having the server decide which certificate to > use based on the connecting client trusted CA. Yeah, sure, but the root certificate to be installed inside the client already lasts 40 years. The system is to be designed to work longer than that, and it not so a good idea to create an even longer "super" root CA. Best, David From nmav at gnutls.org Wed Oct 31 18:45:02 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 31 Oct 2012 18:45:02 +0100 Subject: Support for trusted_ca_keys extension during TLS handshake In-Reply-To: <87804DA7-FE6A-4F84-B377-7E0C40ECD479@googlemail.com> References: <8BC6FA81-F5FA-4564-97E3-1415B228593A@googlemail.com> <87804DA7-FE6A-4F84-B377-7E0C40ECD479@googlemail.com> Message-ID: <5091639E.2000909@gnutls.org> On 10/31/2012 06:40 PM, David Fuhrmann wrote: >> I don't know whether you can apply it in your case, but why not use >> the "traditional" PKI there. Have a root CA to sign all other temporal >> CAs and have all the devices to trust the root one. It sounds more >> elegant approach than having the server decide which certificate to >> use based on the connecting client trusted CA. > > Yeah, sure, but the root certificate to be installed inside the client already lasts 40 years. > The system is to be designed to work longer than that, and it not so a good idea to create an even longer "super" root CA. Indeed, in such a system you'll have such issues. The biggest looks like whether the existing algorithms would stay secure for that long. Nevertheless, if you try implementing this extension it wouldn't be that difficult. regards, Nikos From nmav at gnutls.org Wed Oct 31 19:00:26 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 31 Oct 2012 19:00:26 +0100 Subject: [PATCH 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: <1351691183-88153-1-git-send-email-martin@martin.st> References: <1351691183-88153-1-git-send-email-martin@martin.st> Message-ID: <5091673A.3090609@gnutls.org> On 10/31/2012 02:46 PM, Martin Storsjo wrote: > The code is heavily modelled on the server_name extension > implementation. Hello, Thank you for the patch. After the negotiation though, how does the SRTP layer gets the keys? Or would a later patch make gnutls output SRTP? > Open questions: > - Would it be necessary to add an accessor function for quering > the offered profiles that have been set? > - The profile name strings match the ones used in OpenSSL, but > compared with the RFC, they lack a "HMAC_" before "SHA1". Is > this ok? I don't know. How do you expect users to get those names? If they get it from the RFC then being identical to it would help. Otherwise you may just add a small section in the gnutls manual with the available options. > - Is it ok to have both the setter and getter functions use strings? > The corresponding APIs in OpenSSL set the profiles based on a string, > but expose the selected profile via a struct. see below. > +int > +gnutls_srtp_get_selected_profile (gnutls_session_t session, char *profile, > + size_t *profile_length) I think it would be easier for a user of this function to have profiles in an enumeration and this function to return a member of this enumeration. That may need though a function such as const char* gnutls_srtp_get_profile_name(gnutls_srtp_profile_t) to return a printable name. > +/** > + * gnutls_srtp_set_profiles: > + * @session: is a #gnutls_session_t structure. > + * @profiles: is a string that contains the supported SRTP profiles, > + * separated by colons. > + * > + * This function is to be used by both clients and servers, to declare > + * what SRTP profiles they support, to negotiate with the peer. > + * > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, > + * otherwise a negative error code is returned. > + **/ > +int > +gnutls_srtp_set_profiles (gnutls_session_t session, > + const char *profiles) I see that here a string helps because multiple profiles can be specified. However an interface similar to gnutls_priority_set_direct() would suit better human-provided strings since it would allow pointing out the typo. e.g. gnutls_srtp_set_profiles (gnutls_session_t session, const char *profiles, char** err_pos) btw. Would you be willing to transfer copyright to the FSF? regards, Nikos From martin at martin.st Wed Oct 31 19:10:50 2012 From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=) Date: Wed, 31 Oct 2012 20:10:50 +0200 (EET) Subject: [PATCH 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: <5091673A.3090609@gnutls.org> References: <1351691183-88153-1-git-send-email-martin@martin.st> <5091673A.3090609@gnutls.org> Message-ID: On Wed, 31 Oct 2012, Nikos Mavrogiannopoulos wrote: > On 10/31/2012 02:46 PM, Martin Storsjo wrote: > >> The code is heavily modelled on the server_name extension > >> implementation. > > Hello, > Thank you for the patch. After the negotiation though, how does the > SRTP layer gets the keys? Or would a later patch make gnutls output SRTP? The actual keys for SRTP are generated using RFC 5705, which can be handled via gnutls_prf. (For the context parameter in RFC 5705, one has to manually construct such a buffer to pass as the extra parameter to gnutls_prf, but other than that, it's all there already.) >> Open questions: >> - Would it be necessary to add an accessor function for quering >> the offered profiles that have been set? >> - The profile name strings match the ones used in OpenSSL, but >> compared with the RFC, they lack a "HMAC_" before "SHA1". Is >> this ok? > > > I don't know. How do you expect users to get those names? If they get it > from the RFC then being identical to it would help. Otherwise you may > just add a small section in the gnutls manual with the available options. > >> - Is it ok to have both the setter and getter functions use strings? >> The corresponding APIs in OpenSSL set the profiles based on a string, >> but expose the selected profile via a struct. > > > see below. > >> +int >> +gnutls_srtp_get_selected_profile (gnutls_session_t session, char *profile, >> + size_t *profile_length) > > > I think it would be easier for a user of this function to have profiles > in an enumeration and this function to return a member of this enumeration. > > That may need though a function such as > const char* gnutls_srtp_get_profile_name(gnutls_srtp_profile_t) > to return a printable name. > >> +/** >> + * gnutls_srtp_set_profiles: >> + * @session: is a #gnutls_session_t structure. >> + * @profiles: is a string that contains the supported SRTP profiles, >> + * separated by colons. >> + * >> + * This function is to be used by both clients and servers, to declare >> + * what SRTP profiles they support, to negotiate with the peer. >> + * >> + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, >> + * otherwise a negative error code is returned. >> + **/ >> +int >> +gnutls_srtp_set_profiles (gnutls_session_t session, >> + const char *profiles) > > > I see that here a string helps because multiple profiles can be > specified. However an interface similar to gnutls_priority_set_direct() > would suit better human-provided strings since it would allow pointing > out the typo. > > e.g. > gnutls_srtp_set_profiles (gnutls_session_t session, > const char *profiles, char** err_pos) That sounds like a good idea, I'll return with an improved patch later. > btw. Would you be willing to transfer copyright to the FSF? Yes, that's ok with me. // Martin