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:
WWW-Authenticate:
header field of the reply:
HTTP/1.0 401 Unauthorized -- authentication failed WWW-Authenticate: Basic realm="CollabName", key="encodedPublicKey"
Authorization:
field already with the request,
then the scheme continues at step 3: server checks
authentication and authorization.
After having received the
Step 2: Client Authenticates Himself
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_keyencrypts 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
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.
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
Step 3: Server Checks Authentication and Authorization
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:
(403
status code).
(401
status code). Server sends also a
WWW-Server-Time:
field giving the browser its current
time (this removes the need for syncronized clocks).
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
Step 4: Server Sends An Encrypted Reply
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.
When the client recieves a reply with
Step 5: Client Decrypts The Reply From Server
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