15 June 1999.  SRE-http username/password file                    
 
I.      Introduction
I.a     The  usernames and passwords file (USERS.IN)  
I.b        Examples  
I.c        Advanced options: Dynamic passwords 

                ----------------------------------


I. Introduction

The SRE-http USERS.IN file is used to register users. Each entry in
USERS.IN contains a username, a password, and an optional list of
client privileges.

                ----------------------------------

I.a) The  usernames and passwords file (USERS.IN)  
 
Each entry in the the USER_FILE (with default name USERS.IN) contains an 
optional host nickname, a username, password, and privilege information. It is 
used in two cases: 

  1. When logon is required of a client.
 
  2. When information on privileges is needed.
 
The structure of the USER_FILE is:
    HOST_NICKNAME// NAME PASSWORD PRIV1 PRIV2 ?PRIV_SECRET ...
where
   HOST_NICKNAME// is the (optional) host to which this entry applies
  NAME is the case insensitive username
   PASSWORD is the password, which might be case sensitive 
   PRIV1 ... is an optional list of privileges. 


Note: if a HOST_NICKNAME// is NOT specified, then an entry is valid
for ALL hosts. In other words, when processing USERS.IN "superceding" and
"strict-superceding" hosts are treated as if they were "non-superceding" 
hosts.

                ----------------------------------
 
I.b) Examples  

  DANIEL A11S34WZ SUPERUSER
  MIKE  IOWAMAN    CONSULTANT
  JILL  GOBOTS     INHOUSE
  JOHN  KIOWA      INHOUSE  VENUS  ?JUP1241
  FLOWERS//  CHARLES BROWN PRICELIST
 ANONYMOUS *  PUBLIC
 
In the above example:

   @ DANIEL is given SUPERUSER privileges. This could be useful if DANIEL 
     needs to reset the server from an out-of-town site ... but it could be 
     dangerous (so use an obscure password)! 
 
   @ JILL and JOHN are IN-HOUSE users. Thus, if CHECKLOG=INHOUSE, then DANIEL, 
     JILL, and JOHN are allowed in, but MIKE is NOT allowed in (MIKE is allowed 
     in, given correct entry of his username and password, if CHECKLOG does not 
     equal INHOUSE). 
 
   @ JOHN is given VENUS privileges (as well as INHOUSE privileges). He is also 
     given a JUP1241 SECRET PRIVILEGE (which could be used as a second level 
     "password" in a security conscious addon -- see DYNPWD.DOC for details). 
 
   @ CHARLES has logon rights on the host with HOST NICKNAME of FLOWERS (but not 
     on any other host). 
 
   @ ANONYMOUS is given PUBLIC privileges, and can use any password (and
     is valid across all hosts).
 
    Note that * means "anything matches", and can be used in either the password 
    or username fields. 

Note that all the passwords, in the above examples, are in upper case.
For basic authentication, this does not matter -- the client's authentication
information is converted to upper case. However, for digest authentication
case may matter -- SRE-http checks some, but not all, case permutations of the
password (entered by the user).


                ----------------------------------
 
I.c) Advanced options: Dynamic passwords 

One of the problems of BASIC AUTHENTICATION (the method supported by most 
http/1.0 clients) is that passwords can be easily decoded by a 
"man-in-the-middle". Digest authentication, supported by SRE-http and http/1.1 
browsers, largely solves this problem (by encoding passwords using advanced 
cryptographic techniques). However, until the time that everyone uses http/1.1 
browsers, there is a need for some intermediate technique. 
 
SRE-http provides such a mechanism based on the client and the SRE-http server 
sharing an encoding mechanism. This requires complementary procedures: one that 
SRE-http can use to decode a password, and the other for a clent to encode one 
(i,e.; a program she can run before filling in a password field on the browsers 
authenticaton screen). 
 
For details on this capability, see DYNPWDS.DOC.