On Sat, 2008-07-19 at 16:24 +0200, Iñaki Baz Castillo wrote: > Hi, what should do a server if it receives an "Authorization" header with > no "qop" field when the "WWW-Authenticate" header in the 401 did include it? > > If the "Authorization" header doesn't include "qop" it means that the Digest > response has been computed withour quaility protection (cnonce, nc and so). > > It seems that the behaviour must be "ignore" or "reject" it, but RFC 2617 > uses > SHOULD instead of MUST (again the same): > > 3.2.2 The Authorization Request Header > > qop > ... > This directive is optional in order to > preserve backward compatibility with a minimal implementation of > RFC 2069 [6], but SHOULD be used if the server indicated that qop > is supported by providing a qop directive in the WWW-Authenticate > header field.
That was left that way so that UAs that didn't understand qop would still be able to authenticate using the older standard. If your client understands qop, and the server sends it, you should treat it as a MUST to send it. If you're a server, and you get an Authorization without qop even though you sent it, then it's up to you whether or not to accept the use of the older standard. > I've other doubt. The same section says: > > 3.2.2 The Authorization Request Header > ... > The values of the opaque and algorithm fields must be those supplied > in the WWW-Authenticate response header for the entity being > requested. > > What about if the 401 doesn't include "algorithm" field (so "MD5" is > supposed) > but the client adds it in the "Authorization" header? Same deal as above. -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
