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:
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.
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.
The attack model is presented in a separate document
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:
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.
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.
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
Phillip M. Hallam-Baker CERN Programming Techniques Group hallam@alws.cern.ch Version 1.0R2