this is indeed a __very__ huge patch and it is IMHO quite unreasonable for
one person who was not invloved in the SDES project to check or cross-
this. I've rarely seen such a large patch in an Open Source project. Just
as a hint/proposal: don#T take this into the stable release before many
users have tested this.
Well, just committing parts of it wouldn't have made any sense. I'd love to hear an idea on how to do it better.
A first short note from my side - just by browsing the code: the generic
rename of some
parts from ZrtpControl to SrtpControl may lead to confusion. As an example
out of several: I've seen functions called "setMultistream(...)" or
This is in fact really confusing: SRTP does not have a multistream
feature, SRTP handles
exactly one stream (RTP session). Multistream is a ZRTP feature to avoid
negotiation using public key methods and thus saving CPU cycles and
I don't like that as well. It is the last leftover from ZRTP in the general stuff. But I haven't come up with an idea yet how to separate this out of the general Control without losing the generalization approach.
And although SRTP itself doesn't have this kind of multistream, it could be possible that another key exchange appears which would require something like this.
> I'm now committing the integration of the SDES (also known as S-
Descriptor or SRTP) key-exchange method as an alternative to ZRTP for
secure SIP calls. This is a huge patch-set and I'd ask all developers to
review the commit logs if I touched
"their" code in case I made something you don't like.
> Especially Werner, as I had to adapt some ZRTP stuff as well.
A not completey correct description of SDES above:
Session Description Protocol Security Description for Media Streams.
Ingo's decsription may indicate that SRTP is used to exchange key
material, that's not the case.
All key material is exchanged in the SIP message.
Correct. Sadly lots of clients and literature name RFC4568 simply "SRTP" encryption. And that's why I wrote "aka SRTP".
And here we should issue a big warning to the end user (except Jitsi fully
supports SIP S/MIME
to encrypt data inside the SIP message - but I doubt Jitsi supports this
No, it doesn't (yet? :-).
***** SDES uses SIP message to transport the key data as plain text data.
***** If you use SDES to exchange SRTP keyes then ALL SIP providers MUST
support SIPS (secure SIP)
***** and use SIPS to communicate with your client and with the client of
the called party.
***** If the clients or the SIP providers do not support SIPS then they
MUST use IPsec or an
***** encrypted VPN to communicate.
***** SIP providers MUST communicate via secure (encrypted) channels when
routing the SIP messages,
***** this can be either SIPS or IPsec or an encyrpted VPN
***** Your SIP provider and the SIP provider of the called party can read
the SRTP key material
***** because SIPS, IPsec, or encrypted VPN provide full end-to-end
The SIP account reg. wizard has SDES disabled by default and the option to enable it is already hidden behind a big warning. We could extend this warning with the information you wrote above.
Quote from RFC 4568:
"The SDP security descriptions defined here are suitable for restricted
cases only where IPsec,
TLS, or some other encapsulating data-security protocol (e.g., SIP
S/MIME) protects the
Such an information is IMHO necessary because only a few provides support
SIPS or other
equivalent security protocols. Also a caller cannot be sure of the
provider of the called
party has implemented the same or simliar security protocols.
True. I couldn't find any public SIP provider supporting TLS. But as Stephane already noted, the expected usage is primarily for users inside a corporate environment where e.g. an Asterisk server is running (with TLS enabled).
Thanks for your input!