[asterisk-dev] Improper (?) use of SIP 403 to reject REGISTER for bad auth

[Matthew Jordan]

On 04/08/2013 03:40 AM, Olle E. Johansson wrote:
> 
> 8 apr 2013 kl. 10:33 skrev Nathan Anderson <nathana at fsr.com>:
> 
>> Hey Olle,
>>
>> On Sunday, April 07, 2013 11:15 PM, Olle E. Johansson wrote:
>>
>>> I think this is a very old bug that I implemented. The 403 should be
>>> removed.
>>
>> Thanks for the reply.  If not with a 403 (which I agree with you on), how should Asterisk respond to a REGISTER attempt with invalid credentials?  Should it repeat the 401 status code?  Although I have found people condemning the use of a 403 response in such a scenario, I haven't found a description of recommended "best industry practice" either.
> Well, it goes all the way back to HTTP digest auth, so it is hard to track. There's very few guidelines here. At that point I think I just wanted to stop devices that was badly configured and found that sending 403 stopped the traffic. 
> 
> We should really just re-challenge forever and the client should back off when realizing that the password is not correct - and maybe retry after reconfiguration or after a set time period.
> 
>>
>> Also, does a JIRA already exist for this, or should I open a new one?
> 
> The hard part is what to do with released code. I think it's a serious bug that needs to be fixed, but we can't break the current way of working. I think we have to implement an option that by default is off (existing behaviour) but can be turned on. This hits a lot of users in the head, so it's quite urgent. I wasn't aware of it until a week ago, when a customer had a blackout like you.
> 
> I have no idea if a JIRA issue exist, so search for one or open a new one.
> 

This is an issue for this - ASTERISK-17138

While there is a patch on the issue for this, it merely works around the
problem by commenting out the deletion of the scheduled re-transmit.

The approach advocated by most people on that issue is to have a setting
in chan_sip that implements a 'always retry at some point in the
future'. That's a bit different then not sending a 403 on a failed
REGISTER request.

My biggest concern with implementing a solution that changes the
responses that Asterisk sends is running afoul of alwaysauthreject and
opening up a possible security vulnerability. Going in the other
direction - where Asterisk has a setting that causes it to keep trying
to register, no matter what - doesn't run into those problems.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org