Hello Robert, > I don't think a 2617 update is a good use of time, but I will update > our networking code in the event an update is completed. MD5-sess is > essentially unused. An update should drop it. It is "essentially unused" because essentially nobody created a correct implementation. As for mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=270447 (open since 2004, "Nobody's working on this, feel free to take it" I would if I had some better knowledge of the internal ns... data storage api) I currently implemented a server-side implementation of rfc2617 supporting MD5-sess like specified. Bottom-line of the tests performed is, that nearly any known rfc2617 client-side implementation is more or less broken (programmers seem to tend to cut'n'paste the example code found in the rfc and blindly use it for MD5-sess too, which is plain wrong). To sum up only the most severe mal-implementations: - IE only sends the "opaque" value within the first subsequent request, thus rendering MD5-sess basically dysfunctional (you have to combine the sessionid and the nounce, instead of being able to use opaque for the sid like it is intended) - some netscape descendants tend to use a stale nonce after the server sent an updated nonce - all netscape/mozilla-based browsers recalculate the session-key for each request (see the bug filed above), as well as most other browser implementations (e.g. opera) - opera sends MD5-SESS not MD5-sess - kio-based browsers send qop and algo quoted - nonce-count calculus is broken for most clients I would not drop something, only because it is not widely used as a result of broken implementations -- the better way would be to clarify the requirements for a conforming implementation and the advantages of a working MD5-sess implementation. In fact MD5-sess could be used as a performance advantage, both for client and for server implementations: - both of them need to store some "session state" anyway if using digest auth - usage of MD5-sess saves some MD5-operations (which are usually not cheap if you use the common implementations) Kind regards Ingo StruckReceived on Sunday, 15 October 2006 16:37:11 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:24 GMT