From drogers@datlog.co.uk Sun Oct 3 20:04:30 1993 Date: Sun, 03 Oct 1993 19:30:18 +0100 (BST) From: David Rogers Subject: Security Service Model To: P1003.22@perch.nosc.mil (P1003.22) X-Envelope-to: ferbrache@ajax.dra.hmg.gb MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL22-DataLogic] Content-Type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-Length: 9813 Dear All, Attached below is a generic description of the relationship of APIs and security services. This has been produced after further discussions and work at the X/Open Security Working Group meeting in September. The intention is to next use this model to: - firstly define the security information and operational and management APIs appropriate for each security service, and - then describe the possible variations in security awareness of callers in respect of primary service APIs requiring those security services. -- Regards, Dave Rogers ------------------------------------------------------------------------------- David Rogers Tel: +44 (0)81 863 0383 Data Logic Ltd Fax: +44 (0)81 861 2010 Queens House Kymberely Road Email: drogers@datlog.co.uk Harrow d.rogers@xopen.co.uk Middlesex UK HA1 1YD ------------------------------------------------------------------------------- ------------------------Cut Here---------------------------------- SECURITY SERVICES AND APPLICATION PROGRAM INTERFACES Security Service Model A security service is based on the provision and/or use of security information. The security information is of two types; firstly persistent and established by administrative action, secondly transient and established by operational actions. The provision of a security service can be modelled as below: +------------+ | Caller of | ( STORE Transient | Security | ------ ( RETRIEVE Security | Service | ( PROPAGATE Information +------------+ | Security Service APIs | --------------------------------------------------------------- Security | Security Operational API | Management API | | +------------+ +-------------+ | Security | | Security | Persistent | Service |<------>| Management | Security | Provider | | Information | Information | | | Database | +------------+ +-------------+ Security Management APIs The persistent security information is manipulated by a set of security management services and accessed via security management APIs. The persistent security information can be considered to be held in a Security Management Information Database (SMIB) which is accessed by the security service provider as required. The SMIB requires protection from access by any functions other than the security service provider and the security management functions. That is, the integrity and confidentiality of the SMIB must be maintained. The SMIB is a database of security information associated with the elements of the security domain. The Management Services relate to the installation, modification, listing etc of the security information and the enabling and disabling of a particular security service. That is, the security management APIs are used to control and configure a particular security service. Each security service will have a specific set of security management APIs and a specific set of security information associated with each element within a security domain. That is, each element may have several sets of security information associated with it, one set for each of the individual security services. Security Operational APIs The transient security information is handled by the entities that call the security services. The transient security information is passed between the invoking functions and the security service provider via the operational interfaces to the security services. The Operational Related Services are the means of delivery of the actual security service. The transient security information is associated with a sponsor/principal pairing and represents the security context established to service the principal. The security context has to be generated initially as a result of principal authentication. It then has to be stored and propagated with the thread of execution (the sponsor of the principal) within the system. That is it has to be associated with every process or thread created and executed as part of the session servicing the principal and it must be propagated to any independent service which provides services to that principal. The integrity and confidentiality of the transient security information must also be maintained, including its association with the subject/principal pairing. SECURITY AND OTHER SERVICE APIs A system comprises many different categories of service which in combination provide facilities to perform information processing. Some of these are distinct, such as file system services, memory management services, communication services. However, security is a cross-category service, meaning that it is an inherent part of all other (primary) services comprising the system. All primary services operate within the bounds of a security policy. From the perspective of callers of the primary service APIs the impact of security may be explicit or implicit. That is, the caller may be unaware of any aspect of security as it affects the primary service, or the caller may be aware of some or all aspects of security and required to manipulate the security services themselves in invoking the primary service. This has a potential effect upon the specification of APIs to these primary services. This is illustrated in the examples below. 1) Security Unaware Caller In this example the callers of the primary service are unaware of security and the API to the primary service makes no provision for the control of the security context of the primary service. The implementation of the primary service itself has to include functions to invoke the appropriate security services, eg., authorization, and to handle any security information returned by the service. That is, the primary service API works operates within whatever default security context it is invoked. This default security context will have to have been previously established by security aware functions eg., a login program. In this case the Primary Service API includes no provision for security information within its input and output parameters. However, its behaviour such as success or failure will have to reflect the implicit security policy and its return values or error status codes may include security related failures, eg. authorization failure. Security Unaware Caller of Primary Service | Primary Service API | --------------------------------------------------------------- +------------+ | Caller of | ( STORE Transient | Security | ------ ( RETRIEVE Security | Service | ( PROPAGATE Information +------------+ | Security Service APIs | --------------------------------------------------------------- Security | Security Operational API | Management API | | +------------+ +-------------+ | Security | | Security | Persistent | Service |<------>| Management | Security | Provider | | Information | Information | | | Database | +------------+ +-------------+ Figure: Security Unaware Caller 2) Security Aware Caller In this case the Caller of the primary service is aware of one or more security services and will be responsible for handling security information related to those security services. It may interface to these security services in two ways: - Directly, by invoking the security service API. In this case the primary service API may be identical to the security unaware case, or - Indirectly, by passing the security information as parameters to the primary service APIs. In this case the primary service API specification must include the security information, which may be optional parameters. Security Aware Primary Service Caller | | | | Primary Service API | | --- --------------------------- | ( STORE Transient | | ( RETRIEVE Security +------------+ | ( PROPAGATE Information | Primary | -------- | Service | | | Provider | | +------------+ | | | +------------+ Security Service APIs | --------------------------------------------------------------- Security | Security Operational API | Management API | | +------------+ +-------------+ | Security | | Security | Persistent | Service |<------>| Management | Security | Provider | | Information | Information | | | Database | +------------+ +-------------+ Figure: Security Aware Caller Dave Rogers Data Logic Ltd October 3, 1993