[Asterisk-Dev] AES voice encryption for IAX2

[Derek Smithies]

Hi,

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

My view is that we are talking about a protocol reorganisation, to get it 
secure. Thus, the format of the authorisation packets will have to change.
It is possible to set up a secure link - you have read up on the different
security mechanisms out there. Transmitting username in the clear is a 
nono. We just have to find a way to get it to happen.


Derek.
=====================================================================



 
On Mon, 19 Apr 2004, Adam Hart wrote:

> 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
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> 
> 

-- 
Derek Smithies Ph.D.                           This PC runs pine on linux for email
IndraNet Technologies Ltd.                     If you find a virus apparently from me, it has
Email: derek at indranet.co.nz                    forged  the e-mail headers on someone else's machine
ph +64 3 365 6485                              Please do not notify me when (apparently) receiving a
Web: http://www.indranet-technologies.com/     windows virus from me......