[reSIProcate] ClientAuthManager, failed authentication, and infinite loops

[Derek MacDonald]

Ok, I've updated the ClientAuthManager to handle this situation.  However,
tt will try once more than it should when the nonce changes. I'm going to
gather some more information about when the interop workaround is required
and avoid the extra challenge when possible.

--Derek

> -----Original Message-----
> From: resiprocate-devel-bounces at list.sipfoundry.org [mailto:resiprocate-
> devel-bounces at list.sipfoundry.org] On Behalf Of Derek MacDonald
> Sent: Wednesday, February 08, 2006 1:48 PM
> To: 'Martin Dill'; resiprocate-devel at list.sipfoundry.org
> Subject: RE: [reSIProcate] ClientAuthManager, failed authentication,and
> infinite loops
> 
> Hi Martin,
> 
> The ClientAuthMananger chance was done to interoperate with proxies that
> send 401 messages w/ a different nonce when they probably shouldn't; I'll
> change the ClientAuthManager to only try once when the nonce changes.
> 
> --Derek
> 
> > -----Original Message-----
> > From: resiprocate-devel-bounces at list.sipfoundry.org [mailto:resiprocate-
> > devel-bounces at list.sipfoundry.org] On Behalf Of Martin Dill
> > Sent: Wednesday, February 08, 2006 11:22 AM
> > To: resiprocate-devel at list.sipfoundry.org
> > Subject: [reSIProcate] ClientAuthManager, failed authentication,and
> > infinite loops
> >
> >
> > Hi,
> > I have run into a situation where reSIProcate gets stuck in an endless
> > loop
> > of attempting to REGISTER with invalid credentials. Here is the
> situation:
> >
> > 1. App sends REGISTER message to switch
> > 2. Switch replies with 401 Unauthorized
> > 3. App sends REGISTER with authentication to switch, but the user
> entered
> > in
> > the wrong password so the credentials are invalid
> > 4. Switch replies with 401 Unauthorized again, but the reply has a
> > different
> > nonce value.
> > 5. App recreates credentials and tries again. Return to step 3.
> >
> > This happens in ClientAuthManager.cxx, in
> > ClientAuthManager::RealmState::handleAuth().
> >
> > I am under the impression that this is a bug in reSIProcate. From the
> > section 22.1 of RFC3261:
> >
> >    "Finally, note that even if a UAC can locate credentials that are
> >    associated with the proper realm, the potential exists that these
> >    credentials may no longer be valid or that the challenging server
> >    will not accept these credentials for whatever reason (especially
> >    when "anonymous" with no password is submitted).  In this instance a
> >    server may repeat its challenge, or it may respond with a 403
> >    Forbidden.  A UAC MUST NOT re-attempt requests with the credentials
> >    that have just been rejected (though the request may be retried if
> >    the nonce was stale)."
> >
> > So my understanding of this paragraph is that reSIProcate is in error
> > because it is re-attempting the same request when the nonce has changed,
> > when it should only re-attempt the request if the nonce is stale.
> >
> > I should also note that this works properly with the previous version
> > (5761)
> > of ClientAuthManager.cxx/hxx.
> >
> > Thoughts?
> >
> >
> > Martin Dill
> > NewHeights Software
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at list.sipfoundry.org
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel