Revised Access Authorization Spec
luotonen@ptsun00.cern.ch (Ari Luotonen)
Date: Thu, 16 Sep 93 14:42:57 +0200
From: luotonen@ptsun00.cern.ch (Ari Luotonen)
Message-id: <9309161242.AA22466@ptsun00.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Revised Access Authorization Spec
Status: RO
I appreciate all the comments -- both positive and negative -- about
the AA documentation that I have received -- both publicly in this
list and privately.
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 steps,
and giving the reply is a third step (the original Access
Authorization is therefore split into three parts).
* As a result of authentication process server gets the following
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
* Authentication can be done by two authentication schemes
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).
* Access authorization takes place if authentication succeeds.
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:
- Access Control List contains triples (not tuples):
template : method,method,... : group,user,group,...
- the existance of ACL *alone* results in access authorization
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)
* authorization check procedure is always the same -- in fact, there
only exists one access authorization procedure
* the reply from server in "basic" scheme does not differ in any way
from a reply from a public server (i.e. when the document is sent)
* the reply from server in "pubkey" scheme is either encrypted or the
same as in basic scheme
* the form of reply is really controlled by a protection scheme (this
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")
* all the requests and replies may contain Message Integrity Checks
(MICs)
* The status line is no longer used to indicate the scheme that the
server uses; if there is the 401 [Unauthorized] status code, there
are "Authenticate:" fields indicating the valid schemes:
Authenticate: scheme scheme-specifics
For current schmes these are:
Authenticate: basic
Authenticate: pubkey server's_public_key
* Server id is given in Server-Id: field.
* There may (but does not have to) be a "Protection-Template:" field
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).
* A given server supports a fixed set of authentication schemes, i.e.
this set may not vary according to which ducument is being
accessed. Otherwise this would complicate either rule or ACL file.
* Because of the separation of authentication and authorization, the
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*.
* The used protection scheme is clearly indicated by the header
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 protection schemes *if*so*should*happen*, that we need
more than the Common Library will contain.
* The protection schemes are: none, MIC only, encrypted by DES-CBC
Every client implementation supporting AA must support DES-CBC, but
needs not support anything else.
* I request a discussion about which encryption algorithm to use, it
is easy to M-x replace-string DES-CBC to something else.
* 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
fields:
- DEK-Info identifying the body encryption algorithm and the
DEK (Data Encryption Key), and
- header-MIC (header integrity check, should this be HIC ;-)).
Reason for this is that the header lines contain so much material
that is always the same that it compromises the encryption key.
* DEK-Info field:
- 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:
DEK-Info: algorithm, encrypted_DEK
where algorithm is as described in RFC1423, currently only
DES-CBC will be implemented in the common library.
* Therefore there is no need for a second status line.
* In pubkey authentication scheme, the uuencoded and encrypted (by
server's public key) authentication string is no longer:
username:password:browser_key
but is now:
username:password:browser_inet_address:timestamp:browser_key
Adding browser's internet address and timestamp reduces radically
the possibility of replaying, and therefore encrypting the reply is
no longer necessary in order to make re-playing useless.
In theory, timestamp could expire within a few seconds. The real
interval is to be specified, and depends on how strictly we require
the clocks to be syncronized. If the timestamp has expired
authentication fails.
If the source address of authentication is different from that
found in authentication string the authentication fails.
* There may be message integrity checks (MICs) in both client request
and server (success) reply. There are two different MICs: one for
message body, and one for header lines (including status line).
If there is one MIC, there is always the other, too.
The reason for not having a single MIC is the need to cache
encrypted documents.
* When computing header-MIC, the body-MIC is included (but of course
header-MIC not, because it doesn't exist yet).
* Browser uses its secret key to encrypt request header-MIC.
* Server uses its private key to encrypt the reply header-MIC
(browser's secret key could be used as well, maybe that would be
better???). Body-MIC is not encrypted.
-- Over and out, Ari --
\\\\Ari Luotonen//////
\\\\WWW Person//////
\\\\\\/\\\\\//////
\\\\//\\\\//////
\\////\\//////
\/\/\/\/\/\/