On Tue, 2009-03-10 at 13:32 -0400, Mark Gertsvolf wrote: > Hi, > > I am working with a SIP client, which adds "qop=auth" parameter in HTTP > digest response even though sipX registrar does not use qop-options > (RFC2617) to advertize qop support. Client registration fails since sipX > registrar does not take into calculation the qop related parameters and > as a result the response does not match. > I was not able to find explicit statement in RFC2617 that use of qop by > the client is forbidden if the server does not use qop-options. > > After a quick inspection of the code it looks like the logic to > calculate the MD5 hash with all the qop related parameters already > exists in HttpMessage::buildMd5Digest. It is just a matter of mining for > these values in the authentication header and passing them into the > HttpMessage::buildMd5Digest method. > > I do not see any harm in extending the calculation to optionally take > into consideration the qop parameters and it will allow more clients to > interoperate with sipX. > > Is anybody strongly opinionated about this? Would there be an objection > against me enhancing the authentication logic to include qop handling in > responses.
I am very much in favor of upgrading all of our authentication challenges to include qop and all the changes that implies, but NOT before 4.0 - the potential for interoperability problems is too great. I've been meaning to re-file an issue on this (the fact that our stack doesn't send qop in its challenges was the very first issue I filed against it - but that was 3 issue trackers ago :-( ). I don't think it's a good idea to process qop & cnonce, etc unless we sent the qop in the challenge. While we may have left out a prohibition on doing that, I think it would be confusing. On the other hand, I feel strongly that we should send the qop="auth" and then we don't have any ambiguity. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
