Re: HTTP2: Authentication
Tim Berners-Lee <timbl@www3.cern.ch>
Date: Fri, 8 Jan 93 16:48:14 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9301081548.AA03037@www3.cern.ch>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Subject: Re: HTTP2: Authentication
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
Dave, I am splitting your message up into bits to keep the threads distinct.
> From: Dave_Raggett <dsr@hplb.hpl.hp.com>
> Date: Fri, 8 Jan 93 13:48:18 GMT
> Authentication
> --------------
>
> I think that every HTTP2 request (not just GET) should include the "From"
> field, and that it is strongly desirable to include the user's full name,
> e.g.
>
> From: dsr@hplb.hpl.hp.com (David Raggett)
>
> The user's name must be easy to extract regardless of the particular variant
> of email addressing scheme.
>
> For some services the server may need to check if the user is authorised for
> this service. In many cases the Internet (numeric) address and the
information
> in the "From:" field will suffice.
I agree that low-level security is all that is needed in many cases.
The IP address is quite good for licensing too.
> Additional security will require a password. I think this should be a header
> in its own right. The "POST" command names a document that you wish to post
a
> response to. That document may not be owned by you so it doesn't seem right
to
> muddle up the authorisation for the POST command with that documents Udi.
>
> so lets have a new header "Password: xyzzy"
The passord certainly shouldn't be in the udi.
The hairy part is that we must be flexible about privacy shemes here.
We may meet one lot committed to kerberos and another group comitted to
something else. So we should allow perhaps for a generic 'Authorization:' field
and a number of rather extensive "refused" condidtions including the ones you
suggest and specifying the sort of authorization required.
rather than put passwords in the clear all the time (a reasonable low level
scheme) the next setp is for the server to send back, along with the refusal, a
random string to be encripted by the user using his key. This prevents anyone
from breaking it unless they can put together the two messages, which is
an extra hurdle. The random string is related to the IP address the guy
originally used and will also time out, of course.
>
> a) your Internet address is not permissible for this service
> b) your user name is not permissible for this service
> c) your password is incorrect
> d) your password is ok, but the time check failed
e) please send a kerberos ticket
f) your kerboeros ticket is no good
g) your IP address has just run out of license see body of message
We should look at Privacy Enhanced Mail -- the requiremenst must be similar.
All these schemes eventually rely on an established net of trusted servers
which doesn't exist right now, so we are putting in hooks for the future.
> Basic need for administrators identify and even to mail users.
yes. dunno about mail. Privacy issues... in general you can record who read and
what was read but not who read what.
> Frequent need for authentication - not just on GET
yes. Much more for checkin!
> encrypt password + time of day to foil copying password
>
> Needless to say the value for the Password header should be composed of
> printable 7 bit ascii characters, excluding white space and control chars.
yes.
Tim