Shen: A Security Scheme for the World Wide Web

Example: Request Signed by client

The most common form of request is a GET. Here a user hallam on host cluster alws.cern.ch is requesting a document. Hallam has authorisation by the host for roles hallam, aleph and www_developer. The server may chose to ignore all or any of these roles and will in any case evaluate them in the context of the server. The authorisation

GET /digest.html HTTP/1.0
Accept: */*; q=0.300
Accept: application/octet-stream; q=0.100
Accept: text/plain
Accept: text/html
User-Agent: CERN-LineMode/2.14shen1  libwww/2.16shen1
Authorised-Roles: digest
Originator-Id: digest
MIC-Head: RSA-MD5, VtJVFGKwoavbBJ8k7ST5zQ==

Example: Reply Signed by server

200 OK here you are
Content-Type: text/html
Date: Saturday 14-MAY-1994 17:55:59
MIC-Info:RSA-MD5, 
    UU+of+signed+digest+of+message..........................==
MIC-Header:RSA-MD5,
    UU+of+signed+digest+of+header+up+to+MIC-Header+field....==

Encrytption: - Request for an encoded object

Encryption may be in two forms, both request and response may be encrypted or the request may be in plaintext and the response only encrypted. The latter situation may often arise when the data requested changes in security status.

Example: Plaintext Request from client

When a document is confidential as opposed to secure the request is made in plaintext. This allows cache relays to function more intelligently. Storing an encrypted document in cache does not present a security risk since the difficulty of interception is much less than the difficulty of breaking the encryption.

GET /crypt.html HTTP/1.0
Accept: */*; q=0.300
Accept: application/octet-stream; q=0.100
Accept: text/plain
Accept: text/html
Uncertified-Key: RSA,MEcEQIB8qResHO0CuCo5WH//xjU/5CD88luEqbI8TFRkiK/f5rqFL71EslP
40RanzygJnJpwE6A2U4VXS2Jhauq5gs8EAwEAAQ==
User-Agent: CERN-LineMode/2.14shen1  libwww/2.16shen1
Authorised-Roles: pubkey
Originator-Id: pubkey
MIC-Head: RSA, RSA-MD5, aHt4W/KV1n4Fli2dMKAylC4POu2+kbZdJN4c+ICxedlhP44r90mUy5sM
+nWojGkNOIiV20c1JK7fP1RboBb4vg==

Example: Reply Encoded by server

HTTP/1.0 200 Document follows
MIME-Version: 1.0
Server: CERN/3.0shen1
Date: Wednesday, 17-Aug-94 13:15:52 GMT
DEK-Info: DES-ECB, 0706050403020100
KEY-Info: RSA, CBfVWFnZQBfkUl8r6YdEawKNEpnQkU+MM1FAmuc2kXdVzaqCkQG0OaJ5TemvuxmV5
NC2xlzwIC9dNUaPYuUybw==
Content-Type: text/html
Content-Length: 395
Last-Modified: Thursday, 07-Jul-94 11:25:42 GMT

Encrytption: - Encoded Request for an encoded object

Example: Request Encoded by client

NULL . HTTP/1.1
Accept: text/html
Originator-ID-Asymmetric: hallam@cern.ch
Recipient-ID-Asymmetric:
Date: Saturday 14-MAY-1994 17:55:59
Key-Info:
Secure-Header: UU+of+header+items+including+real+URL+.......==
MIC-Info: RSA,RSA-MD5, 
    UU+of+signed+digest+of+message..........................==

The secure header contains the following:-

GET /object HTTP/1.1
Accept: text/html

The effective message is thus :-

GET /object HTTP/1.1
Accept: text/html

Example: Reply Encoded by server

200 OK here you are
Content-Type: text/html
Key-Info
MIC-Info:RSA-MD5, 
    UU+of+signed+digest+of+message..........................==
MIC-Header:RSA-MD5,
    UU+of+signed+digest+of+header+up+to+MIC-Header+field....==

Client Configuration File

The following is a draft configuration structure for clients installed in a standard security environment. In a high security environment a separate security product is used.

Password  *                     Security/Examples/passwords
Challenge http://*:5000/basic.html      basic
Challenge http://*:5000/digest.html     digest
Challenge http://*:5000/pubkey.html     pubkey
#Challenge *                    browser

Challenge http://*:5000/crypt.html      pubkey
Respond  http://*:5050/*        ident.cern.ch
Respond  http://*:5000/*        ptsun.cern.ch
Crypt    http://*:5000/*        ptsun.cern.ch

Pass *
 

Server Configuration File

The following is a draft configuration structure for servers. The user hallam has POST access to the URL /file/pem_usage.html through his rights identifier editor and GET access though his rights identifier pem_docs. The user bad is denied access because of his rights identifier restrict, even though he has the identifier pem_docs because the restrict ACL occurs before the pem_docs ACL.

Protect /*       Security/Examples/digest.prot
Protect /basic.html      Security/Examples/basic.prot
Protect /digest.html     Security/Examples/digest.prot
Protect /pubkey.html     Security/Examples/pubkey.prot
Protect /crypt.html      Security/Examples/pubkey.prot


Pass    /WWW*            /home2/hallam/WWW*
Pass    /*      Security/Examples/*

AuthType      Digest
ServerId      SHENdigest
PasswordFile  Security/Examples/passwords
GroupFile     Security/Examples/groups

AuthType      Pubkey
ServerId      SHENpubkey
PasswordFile  Security/Examples/passwords
GroupFile     Security/Examples/groups

Work in progress

To be done list:

• Password scheme using an encrypted password that is decrypted at the receiver end and tested against the standard password file.
• The current system does not perform a cryptographically secure hash of the message body content as it should.
• No provision is made for sending files which are stored in encrypted format.
• The protocol announces itself as 1.0 and not 1.1 as it should.
• The replacement password scheme using the native password file and Diffie Helleman has not been even mentioned.
• The date and time are not within the context of the message digest.
• No certificate system under http yet.
• Need the HTML mods.