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

[Matthew Jordan]

On 04/08/2013 09:32 AM, Nathan Anderson wrote:
> 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,
> 

Good points. I agree with Olle as well - it feels like this should be
solved when Asterisk is registering as well as when it's a registrar.

Do you mind commenting on the issue with your rationale? When this bug
gets worked, I'd like to make sure that it gets solved correctly.

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