Shen Digest Authentication scheme available.

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

Received on Monday, 16 January 1995 09:44:17 UTC