|Summary:||ASTERISK-02699: nonce generation errors|
|Reporter:||Roy Sigurd Karlsbakk (rkarlsba)||Labels:|
|Date Opened:||2004-10-28 05:25:51||Date Closed:||2011-06-07 14:10:33|
|Environment:||Attachments:||( 0) chan_sip-1.0_crypto_nonce.patch|
( 1) ethereal.sip-dump.dat
|Description:||The SIP RFC says that when you retrasmit of a message (REGISTER in our case), the server should answer with the same answer. But asterisk dosen't do that because of the wrong way for building the challange. A nonce (random number used to build the challange) has to be valid for a while, but asterisk currently doesn't include a timestamp in it, so with a retransmit of REGISTER, asterisk will answer the second with a 403, instead of 401, causing the client registration to fail. The attached patch fixes this problem.|
|Comments:||By: Mark Spencer (markster) 2004-10-28 09:20:07|
This patch makes all the nonce variables static global variables so we use the same nonce on *all* registrations? That doesn't sound like a good idea to me.
I believe our register behavior is correct, and I would like you to send a sample debug of where we are sending a different nonce to the same REGISTER request retransmission.
By: Roy Sigurd Karlsbakk (rkarlsba) 2004-10-29 03:59:43
Look at the attached ethereal dump (captured without filtering, sorry). Just make a display filter for SIP and look at packets 12746 and further on. This shows the behaviour that made our clients getting kicked out by erronous 403s
By: Olle Johansson (oej) 2004-10-31 05:36:08.000-0600
From RFC 2617 (HTTP Auth):
A server-specified data string which should be uniquely generated
each time a 401 response is made. It is recommended that this
string be base64 or hexadecimal data. Specifically, since the
string is passed in the header lines as a quoted string, the
double-quote character is not allowed."
So we need to generate a new nonce for each transaction.
By: Roy Sigurd Karlsbakk (rkarlsba) 2004-10-31 05:42:59.000-0600
Still, there's a bug in chan_sip
The attached patch fixes this so people aren't blocked by an erronous 403
By: Olle Johansson (oej) 2004-10-31 07:10:36.000-0600
Is this patch disclaimed, so we can base a patch upon this?
By: Roy Sigurd Karlsbakk (rkarlsba) 2004-10-31 07:14:51.000-0600
"I hereby allow digium all rights to this code"
do I need say more?
By: Olle Johansson (oej) 2004-10-31 10:47:31.000-0600
You need to confirm that you've faxed in a disclaimer according to the bug tracker instructions.
By: Roy Sigurd Karlsbakk (rkarlsba) 2004-10-31 15:37:39.000-0600
Where does it say what I have to fax where?
I haven't faxed anything
By: Clod Patry (junky) 2004-11-01 10:03:14.000-0600
it's all explain in there.
By: Mark Spencer (markster) 2004-11-09 00:06:37.000-0600
I intentionally made Asterisk not transmit the initial 401 and then it sent the retransmitted 401 properly, so I cannot duplicate this problem.
By: Roy Sigurd Karlsbakk (rkarlsba) 2004-11-09 02:13:26.000-0600
The problem was there for several of my clients
The problem was gone after patching asterisk with this patch
The ethereal dump shows the problem in action
What more do you want?
By: Olle Johansson (oej) 2004-11-09 04:15:48.000-0600
rkarlsba: Please confirm that you've faxed in a disclaimer, so I can start looking at this.
By: Olle Johansson (oej) 2004-11-11 14:40:52.000-0600
rkarlsba: Please confirm that you have sent in a disclaimer, otherwise WE CAN NOT use your code within Asterisk, in part or fully.
By: Mark Spencer (markster) 2004-11-11 20:43:29.000-0600
The code IS NO GOOD AND WILL NOT BE MERGED ERGO THE DISCLAIMER ISSUE IS TOTALLY MOOT AT THIS POINT.
The attached patch throws out the concept of the random data actually being random by recycling it across all the calls of a specified time frame. It's a practical, if obviously insecure solution.
I need to figure out how to duplicate your problem, or alternatively login to your machine and actually see the problem take place. When I tried to simulate it here, I was unable to duplicate what you are seeing in your logs. Are you using pedantic=yes or pedantic=no and does it make a difference if you change that value?
By: Olle Johansson (oej) 2004-11-12 01:14:29.000-0600
Markster: Calm down. The disclaimer issue is important, since I think part of this code is good and may be useful, but in a modified way. That is the reason I am stressing this fact. I don't like having to re-invent the wheel.
By: khb (khb) 2004-11-13 00:24:30.000-0600
I looked at the packet trace and it appears to me that this is a bug in the user agent not asterisk. The UA appears to be responding to the challenge twice, first with the wrong nonce value and then again with the correct one. The only explanation is that it is using a nonce value from an earlier registration.
The correct behavior would be to re-register with the entire previous digest. But when you send a new REGISTER request without existing digest, you need to forget it and the old nonce and accept the new one from the server.
Now, Asterisk current chan_sip doesn't do this correctly either! Well, it's not making this same mistake, it just never refreshes registrations correctly, only starts new registrations.
But it's generating the nonce correctly and this patch must be rejected. It is not the fix for this.
The reason that proposed patch works is because it's keeping the old nonce values around to it indeed will match them the next time around, but it's WRONG.
Another note: On the second rejection, Asterisk should also answer simply with a 401 and not with a 403.
edited on: 11-13-04 00:30
edited on: 11-13-04 00:38
By: Olle Johansson (oej) 2004-11-13 09:13:29.000-0600
No response from rkalsba and no fixed patch.
KHB: I agree that the patch in full is not doing the right thing, I've stated that from start.
By: Olle Johansson (oej) 2005-02-03 08:40:50.000-0600
Reopened bug on request from Roy.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-02-03 08:46:06.000-0600
I've tried to fax diclaimer some 10 times or so, and I can't get through.
How can we do this more easily?
By: Mark Spencer (markster) 2005-02-03 23:09:25.000-0600
E-mail a scan to me (firstname.lastname@example.org) to have one on file, but this still leaves things up in the air... We've pretty much agreed that the patch is not good as it makes the nonce non-random, so what are we trying to accomplish here anyway?
By: Mark Spencer (markster) 2005-02-10 01:54:16.000-0600
Perhaps you can get an updated dump off latest CVS if you think this is still a problem?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-02-10 04:11:42.000-0600
Do you mean this is fixed in CVS?
It's very time-consuming reproducting it, since it only happens every now and then.
By: Mark Spencer (markster) 2005-02-27 18:53:00.000-0600
I think 3663 has a better sense of what this problem really is.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-02-27 19:53:02.000-0600
I beleive 3663 hasn't posted any dumps yet, so perhaps this bug should be held open and 3663 be flagged as a duplicate?
By: Olle Johansson (oej) 2005-03-10 23:57:28.000-0600
rkarlsba: Reminder: Has an scanned disclaimer been sent to Markster?
By: Mark Spencer (markster) 2005-03-30 01:09:00.000-0600
Suspending due to inactivity / lack of interest.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-06-02 05:43:45
By: Olle Johansson (oej) 2005-06-02 05:53:40
Thank you for sending your disclaimer. Will take a look at some of this code in combination with another patch I have in storage.
By: Olle Johansson (oej) 2005-06-04 07:17:24
Since this patch will not enter CVS without change, I am re-closing this issue report. I will hovever take benefit of the disclaimer and rework the patch and use the useful parts. Thankyou rkarlsba for disclaiming this code!