SESAME is a comprehensive framework for secure distributed environments. The SESAME project was initiated by the Commission of the European Communities, CEC, to demonstrate the usability of then ongoing standardization work with ECMA. After achieving the initial goals, the SESAME project was continued by three major European computer and software manufacturers; Bull, ICL, and Siemens Nixdorf. This work resulted in version 4 of SESAME in 1995 [PP95].
SESAME provides an infrastructure that allows secure client/server interactions over a network. From the point of view of an application, interaction with the SESAME system is through the Generic Security Service API [Lin97] (for more information on GSS-API, see section 3.4.1).
Figure 7.3 shows the main components of the SESAME framework. In a typical sequence of events, a user starts by identifying herself to the SESAME system through a special user sponsor application. The user sponsor forwards the user's request for authentication, along with the user's password, to the Authentication and Privilege Attribute client. This special program contacts the Authentication Server running on the Domain Security Server machine. If the authentication is successful, the AS returns a Kerberos style ticket for the Privilege Attribute Server (PAS).
The ticket for the PAS is later used by the Secure Association Context Manger, SACM, to obtain a Privilege Attribute Certificate, PAC, and a ticket for the Key Distribution Server. When a client application wants to initiate secure communications with a remote server, the application calls upon an initialization function within the GSS-API. The API in turn asks the SACM to provide keying information pertaining to the server to be called. The GSS-API initialization call returns a GSS token that contains a ticket for the server and an encrypted instance of the PAC. The token is passed to the server application.
Upon receipt of the GSS token, the server passes it to the target side SACM which extracts its components. The target SACM examines the service ticket and validates the supplied PAC using the PAC Validation Facility. If the PAC and ticket are valid, a local access control check is performed before a return token is generated. This token contains newly generated dialogue keys that are used for further secure communications. The token is passed back to the server application, that in turn returns it to the client application. The client application must then pass the returned token on to the GSS-API. A GSS-API security context can then be established between client and server. Among other things, the context contains information about dialogue keys and cryptographic algorithms to be used.
Figure 7.3: Main components of SESAME
The basic purpose of SESAME is twofold, to provide an authentication framework and to provide an access control infrastructure. In addition to this, the GSS-API also offers confidentiality and integrity services.
In SESAME, access control is primarily capability-based (see section 6.3.3). A PAC contains the effective privilege attributes of an identity. The attributes are computed using the authenticated identity and active role. A PAC is cryptographically signed by the PAS and includes the identity for which it has been issued. If the target application trusts the PAS, and is certain about the identity of the client, it can validate the PAC and then directly use the access control information there.