Summary:	ASTERISK-01522: [post-1.0][request] Add voice and call control encryption to IAX
Reporter:	hwstar (hwstar)	Labels:
Date Opened:	2004-05-02 20:55:22	Date Closed:	2011-06-07 14:05:11
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Someone was bound to request this, so here goes: In the April 2004 archive of the Asterisk developers mailing list , we kicked aound the notion about how to implement voice and call control encryption in IAX. I understand this is a tall order, but given that Sipura supports SIP level voice encryption in their products maybe it is time to start working on getting the a similar level of encryption support in IAX?
Comments:	By: Mark Spencer (markster) 2004-05-02 22:57:51 General concept for the non-RSA version of IAX2 encryption as it is currently theorized is: 1: NEW is sent specifying a supported encryption system (AES128 would be the first to be implemented) 2: AUTHREQ is sent, also indicating the ability to support encryption 3: Instead of sending AUTHREP with the MD5 hash of the secret and all that, the hash is used as the foundation of the AES key that is used to transmit the response back.   4: If the called party can use that one-time key (from the hash) to properly decode the response, then it's able to continue the call.   5: In a transfer, the one-time key is sent in the TXREL to the parties so they can continue the conversation without sacraficing the security of further calls. Anyway this is just the thinking for the initial stuff.  If RSA authentication was used, we could use the same key to send a generated key, but it's important that it be able to work without the necessity of public/private key if it's going to work in embedded systems like the iaxy. By: hwstar (hwstar) 2004-05-02 23:40:40 Mark, Thanks for sharing some of your ideas on this. I have a couple of questions: So in step 3 the entire AUTHREP response packet from the initiator is encrypted, and all packets after that point are encrypted with the key generated from the hash? Also, it appears that the called number and calling number are contained within the NEW request. This will mean that someone could do traffic analysis on called and calling numbers. I suspect this is a limitation that will be difficult to resolve without radically changing the IAX protocol however. Steve. By: Mark Spencer (markster) 2004-05-02 23:52:10 In step 3, the entire AUTHREP response (except, presumably, scallno and possibly dcallno) would be encrypted. If the called/calling number are an issue, the NEW can be setup with no called number calling number, and then a DIAL request can be sent.  DIAL already is used with DPREQ/DPREP, most notably by the IAXY, when the number isn't known ahead of time. The only change to the IAX2 protocol will be the necessity of accepting callerid in the DIAL if it wasn't specified in the original. By: stevekstevek (stevekstevek) 2004-09-27 13:17:44 As discussed in the IAX2 breakout at astricon: Two issues with this plan: 1) Known plaintext attacks:    Because the same key is used for a possibly long-lived call, and because silence is likely to be present for long durations, a known plaintext attack seems feasable, similar to the attacks which make WEP useless. 2) Sharing the key:    During a transfer, the key is sent to a third party.  Using this key, the third party could decrypt parts of the call they weren't expected to.  Examples: a) User (A) makes a call to discuss something secret via box (B).  After that portion of the call, they transfer to box (C) for another secret call.  box (B) can now decrypt the call to box (C), and vice-versa. These two particular attacks could be solved with rotating keys, and with direct negotiation when transferring, but I suspect that there's probably other attack vectors we're missing. One issue with this plan is that by sending the key to a third party, the third party would then be able to reconstruct the previous portion of the call By: twisted (twisted) 2004-10-27 15:56:39 All I've gotta say is. YAY!  Hopefully we can move along on this topic, as I believe DUNDi makes use of similar methods.  Mark? By: twisted (twisted) 2004-11-14 21:12:40.000-0600 I'm not going to close this one just yet, but poke and prod at it to see if it will come back to life.  This will be the last attempt, however. By: hwstar (hwstar) 2004-11-15 14:44:29.000-0600 I started this thread with the hope that some useful discussion would occur on how to implemment encryption in IAX2. Since the debate has been stalled for the past two months, maybe it's time to close this one bugnote out, and re-open a new one once someone has some code ready to test. Steve. By: twisted (twisted) 2004-12-01 00:52:28.000-0600 Closed per opener. (confusing, ain't it?)