[asterisk-dev] SRTP and forcing encrypted calls

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

> We also need to be able to have a property on the bridge  - like the meetme. 

This makes sense and seems like something we would need to me.

> - inbound call with SRTP
> - outbound call to forking SIP proxy
>   - 183 with RTP from one server
>  - 200 OK with SRTP
> 
> SHould we play the early media if we have a security requirement?

If we have required SRTP (media), we haven't offered anything other than RTP/SAVP. If the 183 comes in with non-encrypted audio, I would think that something on the other end was broken. So, in my opinion we would just ignore the response.

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

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

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

Terry



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100210/5ae62823/attachment-0001.htm