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