Public Key Protection Scheme Proposal

In the Basic Protection Scheme the password flies trough the net unencrypted, which is not a very good idea. One solution to this is to encrypt username and password with a public key of the server.

Furthermore, the documents might be classified or copyrighted in such a way that they need to be encrypted, too, while transferring them through the Internet.

The Public Key Protection Scheme consists of the following steps:

  1. (Server sends an Unauthorized status).
  2. Client authenticates himself.
  3. Server checks authentication and authorization.
  4. Server sends an encrypted reply.
  5. Client decrypts the reply from server.

Step 1: Server Sends an Unauthorized 401 Status

 On reception of a request to access a protected document the Public Key Protection Scheme works otherwise like the Basic Protection Scheme, except that the WWW server sends also its public key in the WWW-Authenticate: header field of the reply: 
        HTTP/1.0 401 Unauthorized -- authentication failed
        WWW-Authenticate: Basic realm="CollabName",
                                key="encodedPublicKey"
Note: If the client had given the Authorization: field already with the request, then the scheme continues at step 3: server checks authentication and authorization.

Step 2: Client Authenticates Himself

After having received the Unauthorized status code (or otherwise knowing from a previous request to the server that it requires authorization information when accessing the desired file), browser prompts for username and password (unless already given), generates a random encryption key, then concatenates the user name, password, browser's IP address, timestamp and the generated encryption key, with colons as separators: 
    username:password:browser_inet_address:timestamp:browser_key
encrypts the gained string with the server's public key, and encodes it into printable characters.

The client then sends the encrypted string along with the next request in the Authorization: field as follows: 

        Authorization: Pubkey encrypted_string
Note: Although browser's encryption key exists only in it's memory and in the server's memory, and is encrypted with the server's public key while it flies through the network, the same key should not be used twice, but a new key should be generated even when accessing the same server, thus reducing the possibility of encryption key being cracked.

Browser's encryption key is concatenated with the identification information before encryption to guarantee, that even if someone catches the authorization string it will be useless, because using it will produce undecryptable results. Thus replaying is possible from the same internet address as the original request during the (short) time when timestamp is valid, but useless.

Step 3: Server Checks Authentication and Authorization

When the server receives an access request to a document protected by the Public Key Access Authorization Scheme, and the request is a full request containing Authorization: field which contains the Public Key Scheme authorization information, it will execute the same Access Request Validation Procedure as in Basic scheme with the following exceptions and additions:
  1. The authorization string is decrypted with servers private key after decoding it from printable characters.
  2. If access information is correct, result should be five fields with colons as field separators. Those fields contain username, password, internet address, timestamp and browser's encryption key, respectively.
  3. IP address is checked with the actual requesting address. If no match access is forbidden (403 status code).
  4. Timestamp is checked with current server time. If not within limits access is denied because of failing authentication (401 status code). Server sends also a WWW-Server-Time: field giving the browser its current time (this removes the need for syncronized clocks).

Step 4: Server Sends An Encrypted Reply

In the Public Key Scheme, if the client is allowed to access the document, the reply from server may be encrypted. Server replies with the usual status line, and immediately after that follow the DEK-Info:, Key-Info: and MIC-Info: fields (almost as in RFC1421): 
        HTTP/1.0 200 Document follows
        DEK-Info: DES-CBC,BFF968AA74691AC1
        Key-Info: DES_ECB,DJSFo7dSDFf34hKHFD8234jDFf2bfasdf832DF3nZ
        MIC-Info: MD5,
         LDKJF3kr34hfDuf23r98FBk38ftDFP9873hbrFDp9gb23kfDPF2b3JfKeL7G
         DLkwtDICl234FJi9834kjfslk
        ... other headers and the encrypted document follow ...
The document body is not encoded into printable characters, but is pure binary as output by the encryption procedure. This is to save time, space and bandwidth.

Step 5: Client Decrypts The Reply From Server

When the client recieves a reply with DEK-Info:, Key-Info: and MIC-Info: it knows that the body is encrypted. These fields are used to decrypt the document as described in RFC1421.

In further discussion about the Public Key Scheme there are considerations about possible encryption methods to use.

AL 12 December 1993