11/7/2000 --- Authentication

- Authentication: to determine the authenticity of message content and
  message origin.
  
  A server needs to establish the origin of a message (and the
  authenticity of the content) before it can decide whether to grant
  the request or not.

- Assumption in the rest of this lecture: confidentiality is not
  important (thus no encryption; everyone can read the message).  This
  is not unreasonable assumption, since often one cares about
  authenticity more than confidentiality (e.g., did this news article
  come from the new-york times? etc.)

- The tools
 
  - Simplified BAN logic:

       - Two statements:
         1. A speaks for B  (we trust A to speak for B)
	 2. A says M  (we heard A saying M)

       - Two rules:
         1. Delegation: if "A speaks for B" and "A says (B says M)",
	    then "B says M"
	 2. Chaining of delegation: if "A speaks for B" and "B speaks
	 for C", then "A speaks for C"
  
  - Signatures (public-key systems)
 
     - Assume a client Alice, a server Amazon, and a message M

     - If Amamzon receives M signed with key Kpriv then Amazon can 
       conclude "Kpriv says M"

     - What we would like to know is whether "Kpriv speaks for Alice",
       because then we can conclude "Alice says M".

     - Whether key "Kpriv speaks for Alice" is an open question:
       - Alice's machine could have been compromised and she might
         have disclosed her private key
       - Alice might have used the key sometime in the past, but she
         has replaced it
       - Is the signature scheme secure?
       - Etc.
        
  - MACs (symmetric-key systems)

     - If Amazon receives a message MACed with key K, that means "K
       says S"

     - What we would like to know is whether "K speaks for Alice",
       because we can conclude "Alice says M".

     - Whether "K speaks for Alice" is an open question:
       - Was K securely disributed to Alice and Amazon?  (K is
         symmetric.)
       - Has Amazon disclosed K (perhaps by accident)?
       - Has Alice disclosed K (perhaps by accident)?  
       - Is the MAC secure?

- Authentication in real systems

  - In crypto systems two parties: Alice and Bob.  In real systems
    many parties are involved.

  - Alice's web browsers sends a request to Bob's web server to buy a book

    - Does Alice web browser speak for Alice?
    - Does the operating system on Alice's workstation speak for the
      web browser?
    - Does the TCP connection speak for Alice's workstation?
    - Etc.

    In all cases there is often a fundamental set of assumption
    necessary to make any of these statements true.  For example:
      - The OS binary is the one produced by the OS manufacturer
      - The login program logged Alice in correctly
	- Alice's password is not compromised
      - The OS does a could job of getting (only) Alice's input in the
        Web browser's forms
      - Etc.

    We haven't talked about:
    - Does the web server belong to Bob?
    - Does Alice's credit card number speak for Alice?
    - Etc.

- Strawman "solution"
  
  - Every entitity is named by public key (Alice, the web server,
    etc.).  We don't worry how the relationship between names and keys
    is established.  This problem is the name-to-key binding problem
    and is related to the key distribution problem that we discuss
    next week.
	 
	 Thus, Alice is named by Ka, Bob is named by Kb, etc.

  - We have some secure components that holds Ka and Kb (a process or
    a smartcard acting securely on behalf of Alice and Bob resp.)
   

    To send an authenticated and confidential request from the browser
    to the web server, we do:

    1. Broswer asks Alice to sign M with Kapriv
    2. Browser asks Alice to encrypt M with Kbpub
    3. Browser sends request to Bob
    4. Bob decrypts M with Kbpriv  
    5. Bow verifies M with Kapub  (Kapub says M)
    6. Bob checks on the ACL whether Kapub should be granted to
    request

    We repeat this for each message between Alice and Bob, and vice versa.


    Done.  Simple and clean.
      - Who cares whether TCP speaks for WS?  The damn messages is
        signed by Alice so "Alice says M".
      - No SSL necessary.
      - No TAOS.

  - What is wrong with this picture?

    - Never use the same keys for encryption and authentication
      OK. We give each entity two key pairs.  Done.

    .... Professor Robert Morris will explain .....