Shen, RFC-822 headers

Considerable effort has gone into reusing as much as possible of the existing IETF PEM specification. It is anticipated that future browsers will provide full access to other network resources such as mail and news, thereby replacing single purpose interfaces. It is clearly undesirable for HTTP to use a separate set of authentication and encryption mechanisms.

Secure Request Example

GET . HTTP/1.0
Date: Today in GMT
Digest-Boundary: RSA-MD5, Random data
DEK-Info: DES-CBC, Initialisation vector for DES
KEY-Info: RSA, RSA encrypted session key
Secret-Header: Encrypted header
MIC-Info: RSA-MD5, digest of message body if present
MIC-Head: RSA, RSA-MD5, Signed digest of head

The secret header is decoded to give:

Anon-Session-ID: Session identifier,thread,index
Relative-URI: The real URL
Authorised-Roles: hallam, system
Uncertified-Key: The key to use to encrypt the reply
Accept: text/html; q=1.0, ...

Notes:

• The method could also be sent encrypted but in most cases the method can be deduced by the presence or absence of a body or the length of the request. Encrypting the method severly impacts the utility of proxies for little extra security. Since many of the unused methods are likely to be purged the field will carry little information in any case.
• The session ID and date are both used as part of the authentication system to prevent replay attacks. Unless the date given is within a specified interval of the request is immediately rejected. Otherwise the session ID is checked to ensure that it has not been used within the date validity interval.
• If the request is given in plaintext the key should be given using a secure exchange mechanism unless it is already known at each end.
• If the request is given encrypted then the key should be a symmetric one. Alternatively the sender may reuse the request session key.

Secure Reply Example

HTTP/1.0 200 OK
Digest-Boundary: Random data
DEK-Info: Initialisation vector for DES
KEY-Info: RSA encrypted session key
Secret-Header: Encrypted header
MIC-Info: RSA-MD5, digest of message body if present
Content-Length: Length of message content
MIC-Head: RSA, RSA-MD5, Signed digest of head 

Binary encrypted body

Where the secret header contains:

Content-Type: text/html
Date: Date of creation of content.

Differences between Shen and MIME versions of PEM

• HTTP is 8 bit clean. The PEM armouring and cannonical forms are not used.
• Session keys may also be used with shared key encryption.

Rationale for using session keys with shared key encryption.

If a document is restricted so that it may only be sent in encrypted form it is convenient to store it in an encrypted fashion using a randomly selected session key. In such a case it is inconvenient and unnecessary to decrypt and re-encrypt.

A similar situation occurs where a firewall proxy is being used to add public key encryption. When a document is received by the proxy the public key encryption must be decoded and the document dispatched to the client under the shared secret key between the client and firewall. It is more convenient to process only the head of the message rather than change the session key. In the case that the client originates the document it is essential that the internal secret key not be divulged outside the firewall.