[Asterisk-Dev] AES voice encryption for IAX2

[Adam Hart]

Derek Smithies wrote:

>Adam,
>
>  
>
>>I shutter at the thought but either way, it's a decision not to be made 
>>quite yet. Let's discuss other issues
>>    
>>
>I hate to think about it also, but, let us get used to it, and move on.
>  
>
Really Mark's call on that, I thought if we iron out some of the other 
issues, the answer will be clearer.

>=============
>Replay attacks are a real problem.
>See, you listen in to one conversation.
>Then, you use their initial packet to "connect with" and you are making 
>some progress toward either a)DOS attack or b)making a call.
>  
>

Random challenges solves the problem of replaying to make a successful 
call. Regarding DOS, I don't think you can prevent it - either method of 
auth requires CPU cycles. I'm open to suggestions though

>Adam suggested:
>  
>
>>NEW (with username :|) ->
>>AUTHREQ <-  (with MD5 challenge and cipher challenge)
>>AUTHREP -> (cipher challenge encrypted by AES using the result of the 
>>MD5 sum as the key)
>>    
>>
>
>
>I see no reason for transmitting the username in the clear.
>If we are going to be secure, we are going to be secure. Consequently, we 
>cannot transmit username in the clear.
>Further,
> Sending New first, and then sending voice (before the authrep/authreq 
> exchange completes)  is nonsensical, as the remote party cannot decode 
> our voice packets.
>
>We could do it as::
> AUTHREQ <-  (with MD5 challenge and cipher challenge)
> AUTHREP -> (cipher challenge encrypted by AES using the result of the 
>               MD5 sum as the key)
> NEW (with username, and other setup parameters) ->
>
>yes, a change in protocol. Well, we better get used to it, cause a change 
>will be required to be secure.
>
>The other change will be that it will take something less than a second
>(guess) to setup a secure relationship, before voice is sent.
>This is quite different to current, where voice starts immediately.
>
>
>
>  
>
And how exactly is asterisk meant to know which user it should 
authenicating against? My model solves the problem of not using public 
key cryptography by exploiting the fact that both parties already have a 
secret.. the password. If you don't know the username, you won't know 
the password.

Of course, we should be using public key crypto when possible, but we 
also need to cater for situations without.

-Adam