Re: RFC2617, was: Straw-man charter for http-bis

tis 2007-06-12 klockan 09:18 +0000 skrev lists@ingostruck.de:

> Ok, maybe another editorial thing to clarify within rfc2617,
> but obviously most implementors share that view.

Agreed, except that would be clarified in 2616 where server is defined..

> Maybe several server impls, but most UAs that I tested did not.
> On the one hand this leads to a performance penalty for the server
> side, because the server needs to calculate the correct digest and
> then the broken digest if the correct one does not match.
> On the other hand it renders what you call the "target of MD5-sess"
> defective: the server *needs* to know H(A1) to calculate the broken
> digest.

Yes, but I don't consider it an argument to drop MD5-sess.

> > How do you do MD5-sess with MD5 for the target of MD5-sess?

> Only operate with H(A1) all the time. Only calculate H(A1) once
> within the UA. At least for mozilla/firefox I know that the UA really
> calculates H(A1) for every single request (!), which is simply waste.

Let me ask the question again: How do you implement the equivalence of
MD5-sess on the server side using just MD5, when the server side account
database do not allow the Digest server direct access to the static
H(A1) hash?

The whole point of MD5-sess is to allow Digest implementations where the
Digest server do not even have access to the static H(A1), only a
session specific hash.  If the server has access to the static H(A1) or
the plaintext password then there is not really much reason to use
MD5-sess.

> > The target of MD5-sess is to allow Digest to operate without requiring
> > the Digest server to have access to the static H(A1) (somewhat security
> > sensitive).
>
> No. At least that's not explicated in the spec.
> The spec only says that MD5-sess has the following purposes
> - allow for "efficient 3rd party authentication servers" (3.2.1)
> - prevent that the server needs to know the user's plain text password
>   "so that the web server would not need the actual password value" (3.2.2.2)

> But it is pointed out, that the server does not need the plain text value
> anyway (Note in 3.3, second paragraph).

Right. Some of the fine print got lost in the RFC. Should be corrected.

> Of course you are right, that -- if the UAs properly implemented it --
> a web server would only need "the session key" passed over from a
> "3rd party authentication server".

And that is the purpose of MD5-sess.

The difference between MD5 and MD5-sess is that MD5 has a static
password seed, while MD5-sess is using a session unique (per server
nonce) password seed.

> But the spec says that 
>  "The specification of such a protocol is beyond the scope of this
>   specification."

Indeed. It's part of the protocol schemes for authentication servers.

The IETF Digest extension for RADIUS is one such protocol. Unfortunately
"crippled" such that the RADIUS server is only allowed to hand out the
session key if qop -int is used, this because the Radius people do not
agree that it's useful to have a limited session maintained at the web
server based on session-unique MD5 hashed keying material and says every
request should go to the RADIUS server.

Regards
Henrik