PATCH - improvement for Negotiate authentication

[Karsten Künne]

On Friday 24 September 2004 08:47, Dawit A. wrote:
> On Friday 24 September 2004 06:01, Waldo Bastian wrote:
> > On Friday 24 September 2004 01:29, Dawit A. wrote:
> > > On Thursday 23 September 2004 14:31, Karsten Künne wrote:
> > > > Regarding HTTP authentication we should have all the bases covered
> > > > now. A couple things still remain. First, should the order in which
> > > > kio_http tries authentication methods be configurable? It's currently
> > > > hardcoded with "NTLM" trumps "Negotiate" which is preferred over
> > > > "Digest" which is preferred over "Basic". But bothering the user with
> > > > that stuff might not be a good idea on the other hand because most
> > > > users probably don't know what this is all about and the current
> > > > order works well in almost all cases.
> > >
> > > IMHO nothing should trump "Digest" if multiple authentication schemes
> > > are returned by the server. However, if a server sends "Negotiate" and
> > > we support that mechanism, then we should negotiate with it and use
> > > whatever it suggests. In the absence of "Negotiate" the order of
> > > preference should IMHO be kept "Digest", "NTLM" and finally "Basic".
> >
> > Do I understand correctly that both NTLM and Negotiate allow passwordless
> > authentication (Or does NTLM still require the user to enter a password)?
> > If they are passwordless they should be preferred over Digest.
>
> It depends entirely on implementation. For our case, i.e. stock KDE, the
> answer I think is NO. I say that simply because AFAIK we do not provide
> single sign-on service by default in our desktop. In Windows, you
> might/might not be prompted for password based on your browser's setup.[1]
> As such my previous statement was based on the fact that there is no signle
> sign-on service in KDE. In that case the strongest authentication scheme
> should be preferred. Digest is stronger than NTLM. [2] However, I am not
> sure if it should be picked over Negotiate. If the server responds
>

In our case NTLM will always prompt for a password because we don't have the 
Windows login password around as IE on a Windows box has (if the client is in 
the same domain as the server). On a Windows box they do even more shortcuts. 
If IE and IIS detect that they're running on the same box the IIS just hands 
over the security context to IE without any further authentication exchanges 
(could be an option if someone ports kdelibs to Windows, in that case the 
whole Negotiate/NTLM thing should also be rewritten to use SSPI).

> > In that case the remaining issue is whether NTLM or Negotiate should be
> > preferred when both are offered. I guess this depends on which one tends
> > to work better.
>
> AFAIC we should prefer Negotiate over NTLM if we support it.
>

I agree. If Negotiate uses Kerberos (which is the only option we currently 
negotiate) it's the strongest IMO and we should prefer that. I created a 
patch which changes the order of authentications to the following:

Negotiate > Digest > NTLM > Basic

It required some fixes in http.cc as well in order to handle the fallback from 
Negotiate to NTLM correctly (patch is attached). I tested this against my 
Apache server and IIS. But currently neither of these servers advertises 
Digest so I'll have to see how I can test that. The following combinations 
are tested:

- Negotiate + Basic (Apache): in case Negotiate fails it falls back to Basic 
correctly

- Negotiate + NTLM (IIS): it falls back to NTLM correctly in case Negotiate 
fails

There is still some room for improvement but I can't promise that I'll be able 
to work on this soon. In the IIS case the server apparently always advertises 
Negotiate + NTLM but it also accepts the NTLM messages on the Negotiate 
mechanism (this is what IE does if you don't come from a kerberised (Active 
Directory) machine, it just sends NTLM messages but with "NTLM" replaced with 
"Negotiate"). So, if we detect this situation (server advertises Negotiate 
and NTLM) AND the Kerberos thing doesn't work (gss_import_name or 
gss_init_security_context fail) we could shortcut to NTLM directly and avoid 
the unnecessary roundtrip to the server. It requires to keep some status for 
the different mechanisms around. If I can find some spare time I'll see 
whether this is feasible.

Another thing I'll keep on my list is to look at the "WWW-Authenticate" header 
which comes on a 200 response under some circumstances in the Negotiate case. 
The SPNEGO/Kerberos draft says it should be fed into 
gss_init_security_context and if the outcome is bad the content should not be 
used (that means, the page should not be displayed to the user) despite the 
200 response. But it's also not very clear how to do that in case of a "POST" 
operation (it can't be done IMO). I did some quick checks on it and so far it 
was always a good outcome. And because this situation apparently only happens 
if you use the SPNEGO mechanism instead of the KRB5 mechanism (which only 
Heimdal-0.7pre has) I would leave it as it is for now.


Karsten.
-- 
It's a good thing we don't get all the government we pay for.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: authorder.patch
Type: text/x-diff
Size: 2634 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040924/51e982b8/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040924/51e982b8/attachment.sig>