Shen: A Security Scheme for the World Wide Web

Security Scenarios

Any security scheme must start with a consideration of the type of security required, and what costs may be resonably be incurred.

The following security scenarios have been considered:

Categorisation of data.

Public Data

The data has no security restrictions and may be read by anyone. Such data should however be protected from unauthorised tampering or modification however since a reader may perform potentialy damaging actions on the basis of its content.

Copyright Data

Data to be served is copyright but not secret. The owner of the data is willing to provide it to another but wishes to ensure that the other has paid. The objective is to maximise revenue and not to minimise security breaches. Thus it is preferable for a theoretical possibility of an unauthorised user being able to obtain access than for a fee paying user to be denied access.

Confidential Data

Confidential data is that which contains material that is secret but the existence of which is not a secret. Such data include bank account statements, personel files etc. Such material may be referenced by public or copyright data.

Secret Data

Secret data that one which the existence of which is itself confidential. Such data might cover algorithms, the existence of which is a secret.

Most Secret

Secret data which it is necessary to monitor and log all access to.

Responsibilities:

Responsibilities describe the actions which must be performed by the various parties. For example a user receiving a confidential document has a responsibility to keep the document secret. A server distributing the document has the responsibility to perform strong authentification checks before distributing it and encrypt in passage.

Weak User Authentication

A user identity must be established as genuine.Unauthorised access must be improbable but need not be secure from all possible forms of attack.

Strong User Authentication

A user identity must be established as genuine. Unauthorised access must be impossible except by random chance or by access to unknown technology.

Hold Secret

The data must not be disclosed to a third party and an identified party acts as guarantor in this respect.

Transmit Secret

The data must not be transmitted in a form comprehensible to a third party and an identified party acts as guarantor in this respect.

Do not Hold

The data must not be stored. Such data may specify an expiry time after which the data is to be erased.

Do not Modify

The data must not be modified.

Certify

Act as guarantor that the data is bona-fide and untampered with.

Log

Perform logging of all actions concerned with the transaction.

For each type of data, two basic security scenarios may be considered, a data is retreived (GET), or a new data is posted (POST). The PUT method is here considered as requiring the same security as the POST method. In fact there are subtle differences due to the fact that a POST generates a new URL which may be secret whereas a PUT updates an existing URL.

GET Public Data

The Server should certify the data and the client check the certification.

POST Public Data

The server must perform user authentication prior to accepting the document.

GET Copyright Data

The server must perform authentication at either the weak or the strong level as specified by the copyright holder. The client may have the "do not hold" responsibility.

POST Copyright Data

The server must perform strong authentication prior to accepting the document.

GET Confidential Data

The server must perform strong authentication prior to transmitting the document and has transmit secret responsibility. The client must perform strong user authentication prior to acceptance and has hold secret responsibility therafter.

POST Confidential Data

The server must perform strong authentication prior to accepting the document and has hold secret responsibility therafter. The client has transmit secret responsibility.

GET Secret Data

The server must perform strong authentication prior to transmitting the document and has transmit secret responsibility. The client must perform strong user authentication prior to acceptance and has hold secret responsibility therafter.

POST Secret Data

The server must perform strong authentication prior to accepting the document and has hold secret responsibility therafter. The client must perform strong user authentication prior to transmission and has transmit secret responsibility.

Attack Model

The attack model is presented in a separate document

Implementation Issues

Security issues affect every level of operations within an organisation. Encryption and authentification at one level cannot provide security if they are compromised at another. The most frequently successful forms of attack do not rely on interception or cryptanalysis but instead attack areas which are not considered by the security policy.

Traditionaly computer security has been the primary responsibility of the system administrator. In a conventional operating system it is assumed that a system administrator should be able to override all protection mechanisms engaged by users. Responsibility of users has thus been been secondary since they cannot be responsible for actions by the system administrator.

Two separate levels for security policy are defined:

Standard Security Policy.

Security must be provided against all forms of attack. However entities within the organisation exist which permitted unrestricted access to data which is not required by their function.

High Level Security Policy.

Security must be provided against all forms of attack. All data is handled on a strict need to know basis. The default security classification for all data is secret or higher.

In many cases it is undesirable for the users to be able to conceal actions from the system administrator. For example a system administrator may have legitimate reasons for suspecting that an account has been compromised and wish to examine normally confidential data to check for tampering. In commercial situations requiring a very high degree of security such as banking it is undesirable for any data held on computer to be inaccessible to higher authority. A high security policy does not imply that the users of the system be granted a high degree of privacy.

In a high security environmant the system administrator is not the apex of the security pyramid. Although the system administrator has a position of high trust, particularly with respect to traffic analysis type attacks the system administrator is to be prevented from accessing certain data. In this case the policy becomes a high security one.

Impact of Standard Security Policy

The impact of a standard security policy may be made transparent to all users except system administrators. The guarantor in the standard security policy is the host and not the user. A host may comprise a single machine or a collection of machines sharing a common identity such as a cluster.

Clients and Servers are installed on the host as trusted entities. Access to the key database is restricted to the system administrator and the trusted entities. When a trusted client executable makes a request to a server the client is responsible for establishing the rights granted to the user and acts as guarantor in this respect to the server. A server may chose to reject claims to having access. The request is signed with the secret signature of the host. Authentification of the rights claimed is provided by this signature.

The application of the standard security model to the UNIX and Open-VMS operating systems has been considered. In the UNIX operating system the client is installed in a separate account with the SETUID bit set. The secret keys are protected so that they may only be read from this account. In the Open-VMS case the client is installed with a rights identifier permitting access to the secret keys. In both cases access rights to the secret keys for signature and encryption are restricted to the client. Although a user may compile a private executable they will be unable to access to the private keys. They will however be free to set up their own private keys which server administrators may chose to accept or reject in the same manner that they may accept or reject host based keys.

Impact of High Security Policy

The impact of a high security policy is extensive. Substantial costs are incurred in evaluating the need to know criterion. Restriction of the information flow itself introduces inefficiencies through duplication of effort and opportunity loss.

In a high security policy each user must be individualy certified. In the context of this data each user must have