[asterisk-dev] SRTP and forcing encrypted calls

[Terry Wilson]

On Feb 11, 2010, at 1:56 AM, Olle E. Johansson wrote:
> 10 feb 2010 kl. 22.42 skrev Terry Wilson:
> 
>> On Feb 10, 2010, at 2:29 PM, Olle E. Johansson wrote:
>>> I wonder if we should try to raise ourselves a bit above various channel specifics.
>> 
>> That was always my goal. :-) That's why I want to do as much in the dialplan as possible.  We just need to make sure that all of our channels behave consistently--even the ones that don't support encryption. It doesn't do us any good if we store somewhere that encryption is required, and then have the channel code ignore it.
>> 
>>> If we have an inbound call, we can have or require a combination of
>>> - secure signalling
>>> - secure caller ID (identity)
>>> - secure media
>>> - secure IM
>> 
>> Wouldn't caller id be part of signaling and IM be part of media, though? Is there any protocol in existence where you can have secure caller id w/o secure signaling or would not have secure caller id if you did have secure signaling? I admit my lack of experience with much more than SIP and  a little IAX, so if you have any examples in mind, let me know.
> I should propably have said "trusted caller ID". You can get any caller ID over a secure channel, but the question is whether you can verify it or not. And yes, you can have signed Caller IDs without having any other security. (SIP Identity)

I think it makes sense to keep that in mind during the design phase, but since Asterisk doesn't support SIP Identity, yet, there won't be any implementation done for it. I'd like to hone in on just signaling and media encryption (those things that are required for existing Asterisk technologies). Adding to the CHANNEL() function to require signed callerid when it is available shouldn't be very difficult once Asterisk supports it. I would still count IM as media as well.

>>> - incoming call with TLS/SRTP - security requirement for outbound call
>>> - 200 OK with SRTP
>>> - REFER to non-SRTP device 
>>> 
>>> - should we deny transfer?
>> 
>> If we are requiring all bridged calls to be encrypted, then I would say that we would have to deny the transfer.
> Ok. The transfer goes to the dialplan, so we need to make sure that we inherit the properties. I am sure we can come up with some nice examples involving the local channel as well.

Currently the settings are set on a channel datastore that is inherited every time a __channel variable would be.

> 
>> 
>>> - outbound call without security requirement
>>> - 200 OK with one offer RTP and an alternative with SRTP in the same SDP
>>> 
>>> Polycoms do this if configured that way. What do we choose? (if we could parse the SDP correctly :-) )
>> 
>> We yell at Polycom for doing something silly? :-p Essentially that would be saying that we should have both encrypted and unencrypted audio and accept and set up both (much like a video and audio offer), wouldn't it?  I think the code would currently treat this as an encrypted call, but I haven't tested it yet. Last time that I looked at the different phones, Snom, Polycom, and Grandstream all handled this a different way. It is what led me to not supporting "optional" encryption. I vote for, "if we see an offer with encryption that we support somewhere, we go ahead and encrypt the call.
> Yes, the implementations of SRTP vary too much. That's why we need SIPit interoperability testing... And the real stuff, DTLS is nowhere yet - or does anyone know any implementations? MiniSIP is usually early adoptors.
> 
>> 
>>> - outbound call with security requirement
>>> - 200 OK with SRTP for audio, but RTP for video and text
>>> 
>>> - Do we accept non-secured media streams? Or reject the call?
>> 
>> Ugh. Can we just hope that it never comes up and ignore the case completely :-) Under the current paradigm, I'd say reject the call since it doesn't include security for all options. But, I can see how that wouldn't necessarily be what one would want to happen. But I really don't want to have to specify requirements for every different kind of media that could possibly exist. audio/video/text/image/morse code/smoke signals/whatever. :-) It starts to be kind of a pain, dialplan-wise. It seems silly that a client would choose to send encrypted audio, but leave the other media unencrypted. But, people do silly things all the time.
>> 
> Yes. This scenario breaks the same way as the earlier one. But you can likely get a re-invite that adds the insecure streams and with that we don't pass the dialplan...
> 
> I think we have to create a joint document with examples like this and the comments so that we know what we had in mind when designing this. Design is critical here, as with all other major changes (like the peer matching architecture ;-) )

I agree, the design is important. But, I'm not sure the specific cases really affect the overall design much. If anything, it just means going in and adding a line here or there at different points in chan_sip. Right now, I'm looking at the overall design which would be more questions like:

For the initial version, does it make sense to use CHANNEL() like I did in the original post?
How much can we do via the dialplan?
How do we handle "optional" encryption amongst multiple technologies?
What would be the best way to notify someone whether the other side of a conversation is secure?

Pointing out that bridges needed to be considered is certainly a good point and wasn't something I'd thought of. Implementation details like what to do in a particular case, I'm not that worried about. Those things are fairly easy to add at any stage. I would just hate to see SRTP miss the 1.8 release. The code can be very difficult to merge when it gets out of date. Better to have a set of core functionality merged in where anyone can then go in and modify stuff in trunk (even if there are some things missing), than to try to maintain the branch indefinitely to get things "perfect".

So mostly I'm thinking of "big picture" design ideas right now to make sure that I'm not going in a direction that people see any big problems with. Another good place to discuss some design would be to use reviewboard. I'll see if I can't get the new code that has been brought up to date up there soon for people to comment on as well. I also need to go through and document a lot of the code that is already there--much of that has never been done. In addition, I'll see if I can write up a document that explains thoroughly "how it works now". Since this code has been around for a while, it isn't like we're designing in a vacuum. Much has already been written.

Terry