RE: User authentication for the proxy

>We desparately need a way in the protocol to authenticate the user to
>a proxy.  Here's the first draft proposal for public review:

The digest authentication method can be used for authentification along the
whole chain and does not involve sending a password in the clear. It is
intended to replace the Basic scheme ASAP. The next public release of the
daemon and CERN library will have it incorporated. The scheme is :-

Let the password be P, the username be Uthe Realm be R and the hash function 
H(), let the binary operator a^b represent the concatenation of the strings a 
and b.

The Request:-

Request = Start ^ Boundary ^ Secure-Fields ^ Signature ^ 
		Insecure-Fields ^ CRLF ^ Body

Where 
Start = Method  URI "HTTP/1.0" CRLF
Boundary = "Digest-Boundary: "  Algorithm [, nonce] CRLF

Secure-Fields = Any HTTP request fields

Signature = Algorithm, S CRLF
Insecure-Fields = Informational HTTP fields only (TBS)


S = H(H(Boundary^Secure-Fields) ^ Date ^ H(P ^ U ^ "@" ^ R))



Appols for the formatting, this has been changing a few times at Alans 
suggestion and other peoples. The working spec is now on paper:-( and in
C :-).


This scheme is not intended as a replacement for Shen, SHTTP or whatever, 
the aims are:-

1) Authentication only
2) Unconstrained by export controls
3) Unconstrained by patent restrictions
4) Drop in one for one replacement of BASIC scheme
5) Does not compromise high grade security schemes.
6) Password never transmitted en-clair
7) Access key not transmitted en-clair

5) is most important. One area in which a lot of people are interested is in 
setting up Web MUDs MOOs etc. Some people will run such systems to snarf 
passwords, despite warnings people will use the same password on multiple 
machines. If we breach (7) once we can remove the need for the dungeon master to 
ever see the users plaintext password, the password is hashed in the client and 
the hash value transmitted. This communication could be encrypted.

The main objection to the digest scheme is that the password file is all you 
need for access. This is why the scheme does not replace the strong 
authentication schemes in Shen or SHTTP (which should emerge as rsoon as we have 
the two schemes combined.


As far as the proxy scheme goes it simplifies a few things, multiple 
encapsulations are possible for example, leaking authentication information is 
not a security hole (it can only be used within the validity interval of the 
Date, there is also a stronger method of preventing a replay attack but it is 
not practical on a forking UNIX server, it needs threads).


Phill H-B

Received on Tuesday, 29 November 1994 04:07:15 UTC