[asterisk-dev] SRTP and forcing encrypted calls

[Terry Wilson]

I have been working on getting the SRTP branch merged up to trunk. The current work can be found at http://svn.digium.com/svn/asterisk/team/group/srtp_reboot. It is still very much a work in progress.

I would like to ask you, the community, for your opinions on how requiring an encrypted call should look. I think that setting an encryption requirement should be channel and encryption technology agnostic. We need to be able to say "any call that is bridged to this channel must be 'secure'". With the current implementation secure means requiring secure signaling, media, or both. We need to be able to force security also upon incoming call setup.

My proposal is to use a combination of dialplan functions and channel config options. For calls coming in to Asterisk, we will need to be able to reject calls during call setup, which means that we will be relying solely on the config options. For outgoing calls, a combination of config options and dialplan functions can be used with the dialplan functions taking priority.

chan_iax2 uses a combination of forceencryption=yes|no and encryption=yes|no|aes128. With chan_sip, there is currently an option that is encryption=yes|no. There isn't really an RFC-compliant way to offer "optional" encryption with SDP. A call either offers RTP/AVP or RTP/SAVP. So, what the code currently does is it encrypts if it receives a call that is offered with encryption, and it will reject a call with a 488 if encryption=yes is set, but encryption wasn't offered on the incoming call. Some phones offer optional encryption, but different phones do it in different ways and all of them violate the SDP RFC (as far as I can tell). So, in effect, there is no need (in  my opinion) for a "forceencryption" option in chan_sip, since if encryption=yes it will be forced anyway. If a peer is making an outbound call and has encryption=yes, we will offer RTP/SAVP otherwise, we won't. If a call fails due to a lack of encryption on the other end, we can catch that in the dialplan and behave accordingly (fail the call, notify the caller of the issue and offer to make a call without encryption or whatever).

The dialplan also needs to be able to set whether or not an outgoing call should be forced for encryption. Currently, I have it set up to use a new dialplan function (poorly named) ENCRYPT(). ENCRYPT(signaling)=1 or ENCRYPT(media=1) for storing on a datastore whether each should be forced to be encrypted. It has been suggested that instead, using CHANNEL() for this would be the way to go. So how does something like Set(CHANNEL(secure_bridge)=signaling|media|none) sound for setting whether bridged calls should be forced to be "secure". For reading whether a channel is "secure" having something like: CHANNEL(secure_signaling) and CHANNEL(secure_media)

An example dialplan for "try an encrypted call, and if it fails, try an unencrypted call" would be:

exten => _600X,1,Set(CHANNEL(secure_bridge)=signaling|media)
exten => _600X,n,Dial(SIP/${EXTEN})
exten => _600X,n,GotoIf($["${HANGUPCAUSE}" = "58"]?encrypt_fail)
exten => _600X,n,Hangup
exten => _600X,n(encrypt_fail),Set(CHANNEL(secure_bridge)=none)
exten => _600X,n,Dial(SIP/${EXTEN})
exten => _600X,n,NoOp(HANGUPCAUSE=${HANGUPCAUSE})
exten => _600X,n,Hangup

Hangup cause 58 in this example is AST_CAUSE_BEARERCAPABILITY_NOTAVAIL which is what chan_sip and chan_iax2 use for codec negotiation issues. I'm open to other ideas for that as well.

So, comments/suggestions? We want SRTP to be in 1.8, so lets get this hammered out.

Terry