Additional slides if discussing Authentication
----------------------------------------------

[Slide:  Authentication with Authentication Service overlay]

There are two scenarios, Sign on and Use

[Slide:  Sign on]

At sign on, a user types a login command with his name - it does nothing but send a message using a common list of services.

[Slide:  Sign on with file overlay]

The Auth Server maintains two kinds of files

   red:  authentication - these are encryption keys, 
         known only to user and auth server

   green: authorization [could actually be a second service 
          invoked by this one]

   The user key is just his password
   
[Slide:  Sign on with response overlay]

The authentication server fabricates a large response.
   1.  A brand new random number, the session key
   2.  One "capability" for each service requested
   3.  Whole thing is enciphered with user's password
   
   The login program deciphers it and stores
        -  session key
        -  the capabilities
   for future Use
   
[Slide:  Using a protected service]

To use a protected service
    1.  Open a connection
    2.  Send the capability for the service
    3.  send the authentication key
    
The server
    1.  deciphers the capability to get session key & user name
    2.  deciphers the authentication to get user name
        If they match -> service request is OK.
        (can use time to verify they are current,
            provide expirations, etc.)
            
-  No password ever sent over wire - nothing secret ever passed over net
             unless encrypted.

-  Could extend to privacy of the data, but requires high 
   performance encrypt-decrypt - but available at reasonable cost
   
Problems?

  -  If someone wire taps the headers they could attach their own data
  
  1.  Roughly same objection on putting a key set on a dorm room
      "If someone has a pick he can get in."

  2.  Higher security is easy
      a)  checksum the data, encipher the checksum
          and put in header or trailer.
      b)  Insist on a header validated within the last hour.
      c) Service remembers time of most recent invocation
         (per user) and requires monotonic time stamps in use field.
      d) Server remembers IP address of validator, 
         and insists on same IP source if that header is received.
      e) Server remembers time of validation and insists on new 
         validation on each use
         
  3.  Encipher all data - too expensive at the moment?