This is my second [still unofficial and subject to change] proposal,
listing proposed changes to my first proposal. Some changes are
directly as requested by other people, some are modified by me, and
some are modifications made by me without a request, because I myself
have found something wrong somewhere.
* Authentication and access authorization are two different
* As a result of authentication process server gets the following
* Authentication can be done by two authentication schemes
* Access authorization takes place if authentication succeeds.
- Access Control List contains triples (not tuples):
template : method,method,... : group,user,group,...
- the existance of ACL *alone* results in access authorization
* authorization check procedure is always the same -- in fact, there
* the reply from server in "basic" scheme does not differ in any way
* the reply from server in "pubkey" scheme is either encrypted or the
* the form of reply is really controlled by a protection scheme (this
* all the requests and replies may contain Message Integrity Checks
* The status line is no longer used to indicate the scheme that the
Authenticate: scheme scheme-specifics
For current schmes these are:
Authenticate: basic
* Server id is given in Server-Id: field.
* There may (but does not have to) be a "Protection-Template:" field
* A given server supports a fixed set of authentication schemes, i.e.
* Because of the separation of authentication and authorization, the
* The used protection scheme is clearly indicated by the header
* The protection schemes are: none, MIC only, encrypted by DES-CBC
* I request a discussion about which encryption algorithm to use, it
* A reply from a protected server starts with a status line:
HTTP/1.0 202 Privacy enhanced reply follows
* The header lines are never encrypted except for two individual
Reason for this is that the header lines contain so much material
* DEK-Info field:
DEK-Info: algorithm, encrypted_DEK
where algorithm is as described in RFC1423, currently only
* Therefore there is no need for a second status line.
* In pubkey authentication scheme, the uuencoded and encrypted (by
username:password:browser_key
but is now:
username:password:browser_inet_address:timestamp:browser_key
Adding browser's internet address and timestamp reduces radically
In theory, timestamp could expire within a few seconds. The real
If the source address of authentication is different
* There may be message integrity checks (MICs) in both client request
If there is one
The reason for not having a single
* When computing header-MIC, the body-MIC is included (but of course
* Browser uses its secret key to encrypt request header-MIC.
* Server uses its private key to encrypt the reply header-MIC
-- Over and out, Ari --
\\\\Ari Luotonen//////
Authorization is therefore split into three parts).
information:
- did authentication succeed or fail
- who is the authenticated user
- secret encryption key shared by both client and server
and unknown to everyone else
implemented as part of the common library (basic-authenction,
pubkey-authentication), or by other schemes (Kerberos, etc)
for which support is added by instances other than CERN,
CERN only providing a clear interface for external authentication
services (which is also used internally by the two internal
authentication schemes).
Authentication routine returns (among other things) the username
which is used in access authorization. Access authorization part of
the proposal has not changed, except for two things:
being turned on
===>
- therefore rule files do not have to have any "protect" rules
and AA may still be on
- so, protection is off *only* when there is no ACL *and* no
"protect" rule
- therefore it is a "directive" telling that something is
protected even if there is no ACL (because someone forgot to
put it there)
only exists one access authorization procedure
from a reply from a public server (i.e. when the document is sent)
same as in basic scheme
is a term -- or I partly used this as a synonym for Access
Authorization Scheme; now the term "AA Scheme" has been buried to
the mighty catacombs of my personal dead ideas, and there only
exist "authentication schemes" and [document] "protection schemes")
(MICs)
server uses; if there is the 401 [Unauthorized] status code, there
are "Authenticate:" fields indicating the valid schemes:
Authenticate: pubkey server's_public_key
giving a template for URLs that are all protected (this lessens the
so-called "heuristicity" of my proposal -- however, the library
will contain this heuristic stuff because it has already proven
powerful (and I can give a good reasoning why, too, if someone
disagrees), and lacking this field does not result in any
complications).
this set may not vary according to which ducument is being
accessed. Otherwise this would complicate either rule or ACL file.
server does not have to announce which authorization scheme it
uses, because there is only one. The reply may, however, be
encrypted or not depending on server setup -- this we call a
*protection scheme*.
fields in reply. There is currently no negotiation about the
protection scheme -- it is dictated by the server. However,
it is not ment that there are lots of protection schemes; rather
there are hooks to provide the possibility of having multiple
different
Every client implementation supporting AA must support DES-CBC, but
needs not support anything else.
is easy to M-x replace-string DES-CBC to something else.
fields:
- DEK-Info identifying the body encryption algorithm and the
DEK (Data Encryption Key), and
- header-MIC (header integrity check, should this be HIC ;-)).
that is always the same that it compromises the encryption key.
- if it does not exist, reply is in cleartext
- if it exists, reply is encrypted
- there may not be more than one DEK-Info field
- contents is a la RFC1421:
there are two arguments, separated by comma:
DES-CBC will be implemented in the common library.
server's public key) authentication string is no longer:
the possibility of replaying, and therefore encrypting the reply is
no longer necessary in order to make re-playing useless.
interval is to be specified, and depends on how strictly we require
the clocks to be syncronized. If the timestamp has expired
authentication fails.
and server (success) reply. There are two different
header-MIC not, because it doesn't exist yet).
(browser's secret key could be used as well, maybe that would be
better???). Body-MIC is not encrypted.
\\\\WWW Person//////
\\\\\\/\\\\\//////
\\\\//\\\\//////
\\////\\//////
\/\/\/\/\/\/