fre 2003-07-11 klockan 14.57 skrev Adam Aube:
> Kerberos would be a good option, because it's fairly universal - UNIX
> variants have supported it for years, and Windows started supporting it
> with Win2k. You would then just need browser support.
And the SPNEGO over HTTP method proposed by Microsoft is flawed in the
same way as the NTLM over HTTP (but at least they document the flaw this
time), and very much disliked by the Kerberos community the last time I
looked for other reasons..
> Yes, it is really a directory service issue. But since most networks will
> use the directory service that came with their OS, and the OS (not the
> directory service) will likely handle database updates for password changes,
> there will still likely be some OS issues.
Indeed. Support in both is needed. Neither is very hard thou..
The thing with NTLM over HTTP is that it uses the NTLM framework which
already existed in Windows. It is the OS level NTLM framework which
provides single-sign-on, not the NTLM over HTTP protocol. To make the
same thing for Digest a such framework for single-sign-on needs to be
devised.
A suggestion on how these interfaces could look like:
* The user directory needs to provide a interface where remote
applications can get access to the needed information in a secure manner
to verify user credentials. This interface involves two calls
a) Give me a server nounce and realm
b) Give me a MD5-sess HA1 matching the above server nounce
(login and client nounce specified)
The directory needs to internally store either plaintext passwords or
MD5 HA1 hashes (MD5 HA1 can be used as base for MD5-sess HA1). The
requirements on internal storage of the password in a compatible format
is probably the biggest challenge in directory integration.
There is no special needs of a trust on the server application, but the
server application needs to be able to trust the data returned by the
directory. The use of SSL recommended as transport to guarantee the
authenticity of the directory responses (from the correct directory and
not tampered with).
* A OS mechanism whereby locally authenticated users can get access
their own credentials in a secure manner without having to re-enter the
password. For Digest this interface should provide two operations
a) Give me a client nounce
b) Give me a MD5-sess HA1 matching the above client nounce
(realm and server nounce specified by the application,
login is known by the OS and does not need to be specified)
This interface MUST be restricted and only available to locally
authenticated users to get their own data. This is why it needs to be a
OS level feature as it is only the OS who can trustworthy determine who
the authenticated user is.
The OS level support on the client stations does not really require
directory integration, but the server side support does. On the client
station the approach used by Windows can be used where the OS remembers
the password used on login in a secure store not directly accessible by
applications and then provides APIs where applications can make use of
this information in a secure manner. It obviously becomes more secure if
directory integration is used as then the password (or hashed
equivalence) then not need to be stored in memory other than during the
login phase and also allows for other means of logins as long as a trust
chain can be established, restricting who may gain access to which users
credentials.
In both the directory interface and the OS interface the split in two
operations protects the returned HA1 by hashing it with a random cookie
generated by a trusted source (directory or OS), making it effectively
worthless to anyone else outside the session. It still needs to be
transmitted securely however to protect the session.
> > This is also possible, squid supports this, but no browsers do. Also, as
> > the browser would get the password, it /does/ lead to password
> > compromise risks that the digest approach doesn't.
>
> With digest the browser prompts the user for the password, so it's currently
> no more secure from the browser end than basic.
This is only because there is no currently no OS services for Digest
single-sign-on. As a result the only available option is to query the
user for his password as the stupid OS does not provide the needed
information.
Regards
Henrik
--
Donations welcome if you consider my Free Squid support helpful.
https://www.paypal.com/xclick/business=hno%40squid-cache.org
Please consult the Squid FAQ and other available documentation before
asking Squid questions, and use the squid-users mailing-list when no
answer can be found. Private support questions is only answered
for a fee or as part of a commercial Squid support contract.
If you need commercial Squid support or cost effective Squid and
firewall appliances please refer to MARA Systems AB, Sweden
http://www.marasystems.com/, [EMAIL PROTECTED]
