[318] in WWW Security List Archive
Shen Digest Authentication scheme available.
daemon@ATHENA.MIT.EDU (hallam@dxal18.cern.ch)
Mon Jan 16 16:21:18 1995
From: hallam@dxal18.cern.ch
To: http-wg@cuckoo.hpl.hp.com, www-lib@www0.cern.ch, ams@eit.com,
www-security@ns1.rutg.ers.edu
Date: Tue, 17 Jan 95 02:36:19 +0900
Reply-To: www-security@ns2.rutgers.edu
Dear all,
As promised my Digest Authentication proposal is now avaliable, specs avaliable
from:
http://info.cern.ch/hypertext/WWW/Protocols/HTTP/digest_specification.html
The source code is avaliable from:
ftp://ftp.w3.org/pub/www/Shen/WWWLibrary_3.0shen1.tar.Z
This source is ASIS. It is not in fact a Shen release, it contains no encryption
product, these are stripped out. This product performs authentication of clients
to servers only. It is for demonstration purposes only, we reserve the right to
change the spec in subtle ways to screw people up etc...
Notes:-
1) Compared with the EIT S-HTTP scheme this proposal is as secure with respect
to authentication provided a secure mechanism for communicating the shared
secret is avaliable.
2) The scheme is simpler but rather more secure than the Spyglass proposal, in
particular the scheme is secure against a person-in-the-middle attack.
3) The reason why I beleive that we need this level of security is that I would
like to be able to introduce S-HTTP features to the Web through a
security-proxy. This would allow connection by the client via the Digest scheme
and perform S-HTTP style enhancements. This would decouple the use of security
enhancements from the client itself which would aid introduction. For this to be
acceptable however it is essential that the mechanism be as secure
algorithmically as the S-HTTP scheme. The complexity in S-HTTP is to make the
security scheme workable in a distributed system where the degree of trust
between the parties is limited.
This is one reason why I feel the extra complexity involved is justified. It
means that client authours can decouple themselves from the security side of
things until we get closure and in the meantime users can have a realistic
product. I don't think I'm being too heartless though :-)
Note that the requirements for the security proxy look an awfull lot like a URN
proxy as well. There is synergy there :-)
4) Protection against replay attacks is currently via time stamps. Alternatively
the anon session Id scheme could be used.
5) Once a client knows that Digest authentication is required for a site it can
be applied without requiring a fresh challenge key for each request.
6) The scheme is completely idempotent, single request/reply style. I would like
to move to a multiple transation version as part of HTTP/2.0 but feel that this
should also incorporate the possiblity of negotiation of security and other
parameters.
7) The main issue as I see it with respect to implementation of S-HTTP is
whether security is the only area for which negotiation applies or whether it is
more general. In the first case the S-HTTP scheme could be adopted without
modification. In the second it would be better to reorganise the negotiation
header tags quite a bit to permit a more general scheme to be developed.
8) This would have been released before the X-Mass break but I didn't want to
release just before being off the net for 3 weeks. Unfortunately Eric opened the
discussion after I had left :-)
9) The spec has a number of issues and options specified in brackets. Please
refer to these in replies. I'm trying an experiment in structuring the
development discussion and would like to know if people find this approach
useful.
10) Missing from the spec is a proposal on modifying HTML forms to cause hashing
of a field before it is sent :-(
11) I'd like to work on the rest of the S-HTTP proposal ASAP so I would
appreciate comments as soon as possible.
12) I have not put this out on the www-talk list yet. This is a pre-pre-release
only. It has been tested and works on my machines but I haven't tested it on
yours [which might be broken]. I'd prefer to leave off a general announcement
because a lot of people might take it as a definitive release and then we would
not be able to change the protocol.
Phill Hallam-Baker
