[asterisk-dev] SRTP and forcing encrypted calls

[Olle E. Johansson]

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)

> 
>> 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.
Ok. You are right that the other end would be interesting. I'll come up with some other example to tease you... ;-)

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

> 
>> - 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 ;-) )


/O