Revised Access Authorization Spec (Ari Luotonen)
Date: Thu, 16 Sep 93 14:42:57 +0200
From: (Ari Luotonen)
Message-id: <>
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
	- 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

 * 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

 * 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
	- 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:


   but is now:


   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//////