[Asterisk-Dev] libsrtp

[John Todd]

At 1:32 PM -0500 on 5/15/04, Dr. Rich Murphey wrote:
>Would Sipura interoperability be an appropriate practical goal for
>implementing these as Olle suggested?
>
>Are there any compatible soft phones or service providers to test against
>(for those without a Sipura)?
>
>Cheers,
>Rich
>

[snip]


1) Voicepulse has claimed to support the Sipura SRTP standard, and it 
is no secret that Voicepulse uses Asterisk.  This would imply an 
implementation of SRTP in Asterisk, though perhaps they are having 
their encrypted service Sipura customers point to some other 
device/proxy that does the SRTP magic.  In either case, there are 
commercial implementations of server/client SRTP against which 
testing can be performed.  I am uncertain if that also implies a TCP 
TLS implementation in Asterisk, as it seems that there is some type 
of certificate exchange that happens with the Voicepulse setup. 
Perhaps someone with a Voicepulse account can ask.

References:
http://www.mailarchive.ca/lists/comp.dcom.telecom/2004-03/0615.html
http://www.voxilla.com/modules.php?op=modload&name=News&file=article&sid=63


2) I don't think we need cycling keys, and if it's not part of the 
draft, then I would suggest we leave it for future implementations.


3) I'd perhaps see the plan for SRTP going forward in small steps:

      a) Between two Asterisk servers, with a shared secret (i.e.: the 
SIP user auth password doing double-duty, as both the authentication 
and encryption password - no key exchange on a per-call basis)

      b) Next, between Sipura devices and Asterisk servers, with 
shared secrets (if this is feasible, given the unknown methods by 
which Sipura devices key the data)

      c) Lastly, between Sipura devices and Asterisk servers, using 
SIPS key exchange inside the SDP messages (implies TCP and TLS or 
S/MIME)

      d) Zultys also supports SRTP, but my conversations with them on 
SRTP open-source work a few months ago didn't go very far, probably 
due to their perceived lack of customer base in the Asterisk 
community.  I'd like to see SRTP in _all_ end user devices.  (Hello 
to all my friends in domestic surveillance!)


4) The methods by which Asterisk implies secure calls needs to be 
thought out.  The "Dial" command gets Yet Another Modifier, or we 
create some variables that connote what type of security a call is to 
have.  Possible (groan) Dial modifiers:

       ${SRTP-PASSWORD} = override the SRTP password stored in the 
channel description for the next call
       e - Encrypt outbound call
       E - Encrypt outbound call with tone hints
       f - if encryption negotiation fails, do not complete the call 
and hang up (with tone hints)
       F - if encryption negotiation fails, continue to next priority 
(no tone hints)

   Encryption tone hints:
    low(short), low(short), high(short) = successful encryption (tones 
at start of call)
    low(long), low(long) = unsuccessful encryption (tones at start of call)


JT