[337] in WWW Security List Archive
Re: Experimental implementation of SimpleMD5
daemon@ATHENA.MIT.EDU (hallam@axal04.cern.ch)
Tue Jan 24 10:42:18 1995
From: hallam@axal04.cern.ch
Date: Tue, 24 Jan 1995 11:44:27 +0100
X-Vms-To: DXMINT::http-wg-request@cuckoo.hpl.hp.com,DXMINT::www-security@ns2.rutgers.edu
Apparently-To: <www-security@ns2.rutgers.edu>
Apparently-To: <http-wg-request@cuckoo.hpl.hp.com>
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
>One suggestion of Hallam-Baker I think is a very good one and I hope it
>will be considered before the SimpleMD5 specification is finalized.
>That is to authenticate the specific transaction rather than just all
>transactions within a realm. In practice this means requiring the client
>to encrypt the URI requested along with the "nonce" and user password.
>The added security is probably marginal but still worthwhile since it
>is trivial to implement.
The added security is very strong. In fact validating the transaction makes
it possible to use a `security proxy' which adds S-HTTP mode security to
messages from a Digest authenticated browser.
In addition it is possible to make this enhancement very simply and in a manner
compatible with S-HTTP so that we get maximal reuse of the library.
The extra code is negligible: For example:-
GET /top/secret HTTP/1.1
Content-Privacy-Domain: Shen
Content-Type: message/http
MAC-Info: AF004423, RSA-MD5, QWEUbcf2389515==. hallam
GET /top/secret HTTP/1.1
Accept: blah...
And to make it easier I provide a `free' library routine inside libwww that
performs the transformation :
http://dxal18.cern.ch/hallam/WWW/Library/Implementation/HTSig.html
http://dxal18.cern.ch/hallam/WWW/Library/Implementation/HTSecure.html
The idea is to use these hooks to add in the other authentication schemes.
I don't buy the argument that because the Basic scheme was dreadfull we should
replace it with another less than secure scheme. The governing factor is not
difficulty of coding in this area, introduction is much harder to achieve.
Making the scheme compatible with S-HTTP asists here. For HTTP/2.0 I would like
to see the BASIC scheme discontinued. A server or browser could chose to
implement it as part of HTTP/1.0 but not use it in a HTTP/2.0 message.
Security schemes with holes in are worse than no security at all. If people
are invited to trust an insecure scheme and it fails people will start writing
chapters on the Web in the UNIX-HATERS manual.
Within the Patent restrictions and ITAR I would like the `simple' authentication
scheme to be as secure as possible. One reason for this is that we want to use
this scheme as an accelerator for the public key system. Within an organisation
it is very unsatisfactory to have a 1 second RSA penalty per transaction. A
better scheme is to use the public key scheme to distribute a shared secret
database on a regular basis [eg each night]. The Digest scheme is important then
because it will be the most used.
There are a few outstanding questions however -
How should the digest of the message be calculated? It might be quicker to
allow separate digests of the head and body parts since then messages may be
stored ready parsed.
Proposals:-
1) We authenticate the message body
2) All things being equal we make it as compatible with S-HTTP as possible
[But forget any ASN.1 monkey business]
3) The discussion of a security scheme for the Web take place on the mailing
list the IETF has been told is the official forum for such schemes.
4) We get something out fast enough that it can be included in HTTP/1.1
Phill
