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

[Olle E. Johansson]

8 apr 2013 kl. 16:32 skrev Nathan Anderson <nathana at fsr.com>:

> On Monday, April 08, 2013 6:59 AM, Matthew Jordan wrote:
> 
>> This is an issue for this - ASTERISK-17138
> 
> Right, and I referenced this one at the end of my original post.
> 
> The problem is that, as you point out, this addresses the problem on the registering client-side, not the registrar server-side.  I tried (perhaps not successfully) to make the case, though, that what issue 17138 is targeting -- the client-side response -- is technically not where the bug lies.  The Asterisk client code's response to the 403 is in-spec.  It's the registrar server code that shouldn't be issuing a 403 in the first place, as the purpose of a 403 status code is not to reject an invalid authentication attempt, but rather to tell an already-authenticated client that it is not authorized to perform whatever action led to the 403 response (again, see https://lists.cs.columbia.edu/pipermail/sip-implementors/2004-August/006960.html and the surrounding discussion thread).  Thus, it doesn't make sense to respond to a REGISTER request with a 403, unless perhaps a given UAS does not accept registrations to begin with (every peer is configured statically, and you want to di
> scourage hosts from sending REGISTERs of any type).
> 
>> 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.
> 
> The problem with addressing it on the Asterisk client-side by introducing an option to "keep trying ... no matter what" is that 1) rather than fixing conformance to IETF spec on the server side of things where it is broken, Asterisk would be introducing further deviation from the spec on the client side in order (ironically) to work around the behavior on the server side so that Asterisk can interop with its own broken self, and B) *this only solves the problem for Asterisk clients*, not for other spec-conforming SIP UACs.  Not all of our voice clients, for example, are using Asterisk on their end.  If all we do is fix Asterisk client code, that doesn't fix the issue for people using something else to peer with us which behaves the same (correct) way that the Asterisk client code currently does.
> 
> I think the solution to making sure that 'alwaysauthreject' is still effective as a "valid account camouflage" security feature is to make sure that it mimics whatever new behavior the registrar server is modified to perform.  So if, for example, the registrar server code is changed to repeatedly challenge invalid auth requests (sending 401 over and over again instead of sending 403), and the fake auth reject code is made to do the same thing, then I don't see how anybody hitting the server looking for valid usernames is going to be able to distinguish between the two responses.  Also, I think Olle's on the money with the suggestion that any change in behavior -- whether client or server -- be made into a configuration option that is off by default, so as to not unexpectedly break things for those who may be depending on the current behavior.
> 
> Just my tuppence as a victim of this bug,
> 
Unfortunately, in many cases Asterisk has become a reference implementation. We need to fix both sides, since someone may have copied our 403 behavior.

- Restart the client registration without needing to run "sip reload".  Needs a new timer - "registration_backoff=300" or something similar, meaning "do not stop forever at fatal errors - just back off for x seconds and try again"
- Disable the 403 on the registrar side with "dontexposefailedregs"

/O