SESAME Secure European System for Applications in a Multivendor Environment) AN INTRODUCTION Issue 1 February 1993 DENIS PINKAS TOM PARKER PER KAIJSER ICL Informationssysteme AG 7 Rue Ampere Eskdale Road, Otto-Hahn-Ring 6 91343 Massy Winnersh, Wokingham, W-8000 Munich 83 France Berkshire, RG11 5TT Germany UK Tel:+33.1.69.939575 Tel:+44.734.693131 Tel: +49.89.636.82679 Fax:+33.1.69.937353 Fax:+44.734.697636 Fax: +49.89.636.82682 D.Pinkas@frmy.bull.fr t.a.parker@win0109. wins.icl.co.uk CONTENTS Acknowledgements 3 1. Introduction 3 1.1 History 3 1.2 SESAME in a Nutshell 4 2 Terminology and Abbreviations 5 2.1 Terminology 5 2.2 Abbreviations 5 3. Background Concepts 6 3.1 Authentication and Single Logon 6 3.2 Initiator and Target Access Control Information 7 3.3 Pull versus Push 8 3.4 Heterogeneity of ACI 9 3.5 Usability and manageability 10 3.5.1 Roles 10 3.5.2 Customer-defined access control attributes 11 3.6 Uses of Identity 11 3.7 Accountability 13 3.8 Access Paths and Delegation 13 3.9 Primary and Secondary Principals 15 3.10 Cryptography and Key Management 16 3.11 Certificate and Certification Authorities, Public Key Technology 17 3.12 Cryptographic Issues 18 3.13 Secure Conversations and Secure Association Contexts 19 3.14 On-line versus Off-line Security Servers 19 3.15 Security Policies and Security Domains 21 4 SESAME Design 22 4.1 Security Over an Insecure Network 22 4.2 Initiator Machine Architecture 22 4.3 Authentication 24 4.4 Acquisition of Privileges 27 4.5 Target End-system Architecture 29 4.6 Key Management 31 4.6.1 Basic Keys 33 4.6.2. Dialogue Keys 34 4.7 Privilege Attribute Certificates (PACs) 35 4.7.1 PAC Structure 36 4.7.2 Identities 37 4.7.3 PAC Controls 38 4.7.3.1 PAC ownership 38 4.7.3.2 Restrictions Associated with a PAC 40 4.7.3.3 Other PAC controls 41 4.7.3.4 Inter-domain access 42 4.7.3.5 Representation of Privileges 42 4.7.3.6 Accountability and Audit 42 5. Comparison with other Architectures 43 6. Bibliography 44 ACKNOWLEDGEMENTS The authors would like to thank Philippe Caille, John Alcock and Peter Hartmann for their valuable contributions to the production of this document. 1. INTRODUCTION 1.1 History In most systems of today, protection of resources in a distributed computing environment is principally achieved by direct logon to each end- system accessed, using passwords, with users transmitting the password in clear and unprotected. This has a number of drawbacks: firstly it is not very secure, since anybody equipped to listen to the network could learn a user's unprotected password and so be able to impersonate that user; secondly it is not convenient for a user to have to remember several passwords and to have to enter a different one each time he accesses a different end-system, and thirdly the user is not known as one single user to the distributed system as a whole, there is no co-ordination of his or her use of the distributed system across the different servers of the system. To find solutions to these and related problems, work has been underway for the last six years in Europe, under the aegis of the European Computer Manufacturers Association (ECMA), to develop security standards for open systems. ECMA's work has drawn upon the standards formulated in the OSI Architecture, ISO 7498-2, which describes the security services and their position in the seven layer OSI basic reference model, and the series of Security Frameworks developed in ISO/IEC JTC1 [ISO/IEC 10181-1 to 10181-8]. A Technical Report, TR/46 "Security in Open System - A Security Framework", published in 1988, concentrates on the application layer and describes a security framework in terms of application functions necessary to build secure open systems. The continuation of this report, the Standard ECMA-138 "Security in Open systems - Data Elements and Service Definitions", defines the abstract security services for use in a distributed system. ECMA is continuing working on two main topics. The first one, "Security in Open System - Authentication and Privilege Attribute Security Application", defines the functionality and the protocols for a distributed security service in charge of authenticating and distributing access rights to human and application principals. The second topic, "Security in Open System - Association Context Management", describes a model for establishing secure relationships between applications in a distributed system. SESAME (Secure European System for Applications in a Multivendor Environment) is an architecture that implements the ECMA model and provides solutions to the problems described above. The work is being undertaken by Bull, ICL and Siemens Nixdorf Informationssysteme AG (SNI) under part funding from the Commission of the European Communities. Similar work has been done by the Massachusetts Institute of Technology (MIT) which has developed an Authentication Service called Kerberos. The Open Software Foundation (OSF), as part of its Distributed Computing Environment (DCE), has incorporated Authentication and Privilege Services that make extensive use of Kerberos V.5. Digital Equipment Corporation (DEC) has designed an Authentication Service called Distributed Authentication Security Service (DASS) based on their Distributed System Security Architecture (DSSA). Some of the differences between SESAME and these other developments become apparent in the text, and Section 6 gives a brief consolidated comparison. One goal of the SESAME project is to integrate SESAME with OSF DCE. This has resulted in a variant of the SESAME architecture that does not require use of cryptographic public key technology, but this is outside the scope of this paper. 1.2 SESAME in a Nutshell SESAME offers a single point for logon, at which the user authenticates only once whatever application(s) he will be using, and offers the means to ensure that access to services is policed to the appropriate level of security. SESAME achieves this by means of a sophisticated access control technology which includes an Authentication Service and a Privilege Attribute Service. After successful authentication by an Authentication Server (A-Server), the user obtains an Authentication Certificate (AUC) which he can present to a Privilege Attribute Server (PA-Server) to obtain proof of his access rights in the form of a Privilege Attributes Certificate (PAC). The PAC is a specific form of Access Control Certificate as defined in ISO 10181-3, the Access Control Framework. If the A-Server is collocated with the PA-Server the cost of signing the AUC can be avoided, and a default PAC can be returned immediately. It is not only a human being who may be controlled in this way but also an application that may be acting on a user's behalf; both are referred to as "initiators" in this paper. The PAC is presented by the initiator to a target application whenever access to a protected resource is requested. The target application makes an access control decision according to the initiator's security attributes and the access control information attached to the resource. The PAC is protected during its transfer to prevent anybody but its genuine owner or an authorised delegate making use of it. This protection requires a temporary cryptographic key to be established in order to secure the conversations that will take place between the initiator and the target applications. PACs can be used at more than one target, and are protected using public key cryptographic techniques. User data passed in a dialogue between an initiator and a target can optionally be either integrity protected or confidentiality protected or both. At the time of writing, the first major SESAME release is under development. Not all of the features described here will be present in this release. 2 TERMINOLOGY AND ABBREVIATIONS 2.1 Terminology The terminology of the ISO Security Frameworks (ISO 10181) is used throughout this document, supplemented with additional terms for new SESAME concepts that are introduced as needed. In particular, in ISO 10181 humans or system entities that are registered in and authenticatable to the system are known as principals. When acting in an active role, for example requesting access, these principals are known as initiators. When acting in a passive role, for example being accessed, they are known as targets. The term service is used to indicate a coherent set of abstract functionality, which can be implemented as a number of separate servers. A server exists on a single end-system, though may share it with other servers of different services. The terms "he" and "his" are used as an abbreviation for "he or she" and "his or her" in the interest of clarity, with no sexual bias intended. 2.2 Abbreviations A-Server Authentication Server A-Service Authentication Service ACI Access Control Information ACL Access Control List AI Authentication Information APA-Client Authentication and Privilege Attribute (server) Client ATG Application Trust Group AUC Authentication Certificate CA Certification Authority CCITT The International Telephone and Telegraph Consultative Committee CK Control Key CV Control Value DASS Distributed Authentication Security Service DCE Distributed Computing Environment DSA Digital Signature Algorithm DSSA Distributed System Security Architecture ECMA European Computer Manufacturers Association. ISO International Standards Organisation KDS Key Distribution Service. MIT Massachusetts Institute of Technology OSF Open Software Foundation OSI Open Systems Interconnection OWF One-way function PAC Privilege Attribute Certificate PA-Server Privilege Attribute Server PA-Service Privilege Attribute Service PV Protection Value PVF PAC Validation Facility RSA The Rivest-Shamir-Adleman algorithm, an asymmetric encryption algorithm. SACM Secure Association Context Manager SSID Subject Sponsor Identifier TGT Ticket Granting Ticket TTP Trusted Third Party 3. BACKGROUND CONCEPTS In this chapter, basic concepts that relate to distributed system security are discussed. In each case, the approach taken by SESAME in relation to the concept is briefly outlined. Detailed descriptions are given in subsequent chapters. 3.1 Authentication and Single Logon Identification and Authentication are the first prerequisites for access to a protected system. It would not be possible to make access control decisions or make users accountable for their actions if anyone could masquerade as anyone else. In most of today's systems, a principal authenticates to the same system to which he will subsequently be making accesses. It is then a straightforward matter to communicate the fact of authentication to the points of access since they are collocated. In a distributed system a principal wishes to authenticate only once even though he may subsequently be accessing multiple services on multiple servers distributed over several end-systems. This introduces a problem. No longer is the point of authentication collocated with the points of access. Proof that authentication has taken place must somehow be transmitted in a secure manner to the multiple access control authorization logics of the different servers accessed across potentially insecure communication links. Cryptographic mechanisms are needed to help in this task. There are several different ways in which a user may be required to authenticate himself to a computer system. The most common way by far is to use an identity and a password. Other authentication techniques may utilise a machine-readable badge, a smart card, a hand held authentication device, or some immutable characteristics such as a fingerprint. SESAME supports single logon, and is constructed in such a way that different authentication methods can easily be implemented. In every case the value of the authentication information is never sent in clear over the network. 3.2 Initiator and Target Access Control Information In the real world, actions are authorised on the basis of characteristics possessed by the parties involved, the state of the world at the time and the kind of action requested. In the computer world similar concepts are used. Access control decisions are made on the basis of security attributes associated with the initiator (known in ISO terminology as Initiator Access Control Information (Initiator ACI)), security attributes associated with the target object being accessed (Target ACI), the kind of access being requested and the context within which the access is being requested (for example the time of day). In many situations the Initiator ACI can be simply the identity of the initiator, and the corresponding Target ACI a conventional Access Control List (ACL), specifying for each incoming identity the actions available to it. However there are other situations in which Initiator ACI reflecting the initiator's group memberships, job in an organisation or security clearance is more appropriate. In the first two of these cases the corresponding Target ACI might be an ACL containing actions permitted by initiators as members of particular groups or in particular jobs. In the case of security clearance, the corresponding Target ACI would be the security classification of the object to be accessed. In single machine systems all the ACI can be held by the machine's operating system - everything is in the same place; however in distributed systems the question of where the different kinds of ACI are to be held arises. SESAME takes the view that any particular ACI value should be able to be stored once in the system (except for any resilience copies that might be supported). Target ACI should be held with the target, as is common practice in today's systems. Initiator ACI should be able to be stored at the point in the system where information about initiators is kept. So a principal's security clearance, for example, should not be held at each accessed target but should be presented to targets within the certificate the principal obtains to prove its access rights. When a principal's Initiator ACI changes, such as membership of a particular group, it should be possible to manage that change in one place. It should not be necessary to co-ordinate management of a principal's group memberships over multiple target end-systems. A SESAME principal therefore goes through two steps to obtain the certificate needed to access a particular target: it authenticates to a server of an Authentication Service (A-Service) obtaining an Authentication Certificate (AUC), then uses this AUC as evidence of identity to obtain Initiator ACI (known in both ECMA and SESAME as Privilege Attributes but sometimes referred to as access privileges). These are provided and granted by a Privilege Attribute Service (PA- Service) in the form of a Privilege Attribute Certificate (PAC). The A- Service and PA-Service can be separated so that they can be managed by different authorities, and can be flexibly configured to suit installation needs. SESAME also provides for A- and PA-Servers optionally to be collocated. This can bring performance benefits. 3.3 Pull versus Push Given that Initiator ACI is not held at the target, there are two ways in which it can be obtained. It can either be "pushed" to the target by the accessing initiator, or "pulled" by the target from a secure source of Initiator ACI. SESAME supports the push model. This has several advantages: . in terms of performance: an access control decision can be taken immediately by the target without extra communication, . in terms of communication cost: the access to the place where the privileges are held will in general be made less often by the initiator than the alternative of once for every target accessed, . in terms of support for anonymous access: the pushed Initiator ACI need not contain the initiator's identity. If the pull model is used, this identity is needed by the target to retrieve the initiator's ACI, . in terms of tempered ACI: the initiator ACI depends on factors such as the authentication method or the security properties of the location from which the initiator is logging on, . in terms of least privilege: the target should only see and obtain the privileges needed for making its access control decisions, no more. 3.4 Heterogeneity of ACI SESAME is not a proprietary development; it has its roots in the standards work of ECMA and is not tied to any specific end-system types or communications protocols; it is designed for multi-vendor distributed systems. This contrasts with Kerberos for example, which is based on distributed UNIXTM systems. A heterogeneous system user may wish to access UNIX applications and different proprietary mainframe applications all in the same session, and the user's security manager does not want to have to manage separate Initiator ACI for each of these machine types simply because they handle the same global ACI information in different ways. For example if a user's access rights to these applications are based on the user being a member of the invoicing department of a company it should not be necessary to hold this membership information a number of times in the user's PA-Service, once as a UNIX group and once as each of the proprietary forms of group. The ECMA work attacked this problem by defining standard security attribute types for use as Initiator ACI, and which are independent of specific end-system representations. This leads to better interworking potential as well as easier management of Initiator ACI. When a SESAME user is granted membership of a group it can be represented once as Initiator ACI in this global form. On receipt of this value in the user's PAC, it is then the individual end-system's responsibility to map this global form into a locally meaningful form, if necessary. Notice that if the value is one that is being used by the target application itself, rather than by the end-system's operating system, there is no reason why the global form could not be directly understood and used. This would have the added benefit of making the application portable (from an access control point of view) across multiple end-system types since the application is basing its access control decisions on externally provided standard Initiator ACI. SESAME does not insist that the global form is used however; it does permit specific end-system forms where they are more convenient. It is up to the security manager to decide when defining security policy. 3.5 Usability and manageability Good security requires not only that adequate functionality is provided with the required assurance, it also requires that this functionality be easily usable and manageable. To this end it is important that the mapping between the real-world security policy for an enterprise and its instantiation as a system security policy is straightforward and easy to understand. Users need a simple interface to the system and do not want to have to understand and explicitly request all the access privileges they need. The system manager wants to control what privileges users are allowed but does not want to specify each privilege individually for all users and then have to update them individually whenever a user's access needs change, he needs to be able to group them together and handle them in groups. Also many business applications would like to control access on the basis of the job a person is doing in the organisation. In such cases the user's identity need play no part in actual access control decisions. The general ability to define Initiator ACI as well as Target ACI and to use mechanisms other than just Access Control Lists goes part way to satisfying these needs, but SESAME goes two steps further as described below. 3.5.1 Roles SESAME directly supports real world access control policies that are based on the concept of a user's organisational role or job. A user working in a particular role is likely to need particular privileges and controls which give the required access to particular applications and services. For example, he may need to be a member of a particular group and have access to particular target application groups. The administrator defines a set of Privilege Attributes which is associated with a role. He also defines which users can take which roles. At the start of a session, the user can specify one of his role names (or gets a default) which automatically gives him the associated security attributes. Some of the advantages of this are: . the user only needs to know the role name (e.g. quality controller, or pay clerk), not what Privilege Attributes this needs. If he always works in the same role, he doesn't even need to know this, as it will be his default role, . if the user changes job, once the administrator has updated his roles, when he next uses the system, he automatically gets the privileges associated with the new job, . administration is significantly simplified if many users take the same role, as the set of Privilege Attributes for the role only need defining once, . if a specific "Role" Privilege Attribute is associated with the job role, access control in some types of application can be based on this, rather than on individual user identities, thus simplifying administration of the target system. Note that not all users need have roles since in some security policies roles are not relevant. 3.5.2 Customer-defined access control attributes SESAME also permits a security manager to define and register his own ACI types in the form of access control attributes with their own semantics, tailored to the real world policy he wishes to represent. The provision of the access validation logic to analyse them is however outside SESAME's scope. 3.6 Uses of Identity Identity is a real world attribute that has multiple uses in a computer system. Here are some of them: . as a means of claiming who you are, i.e. it is what you present when logging on to a system to help the system locate the authentication information that it will use to verify your claim. Call this use "Logon". . as a means of making you accountable for your actions, i.e. it is the identity that appears in audit trails. Call this use "Audit". . as a means of identifying who should pay for the use of the system. Call this use "Charging". . as a means of obtaining access to protected objects, for example the identity that appears in an Access Control List. Call this use "Access". . as a means of identifying you as the originator of a piece of data so that the receiver can prove to a third party that the piece of data really did originate from you. Call this "Non-repudiation". . as a means of locating and permitting the release of your Initiator ACI within a Privilege Attribute Service. This is a special case of the "Access" use. Call this use "Privilege Attribute Access". All of these uses could be encompassed by implementing one single type of attribute: "Identity Attribute" used for everything, and this is commonly done; however this results in there being a number of security policies that are impossible to implement, in fact all policies that require different values for different uses. One simple example is where Tom is to be able to use Jerry's identity to access the system for a period (say Jerry is on holiday). He is permitted to do this with respect to accesses to all objects except access to Jerry's other Privilege Attributes, so Tom would not be able to use the identity "Jerry" for "Privilege Attribute Access" purposes; in particular he would not be able to obtain Jerry's security clearance or group memberships unless they also were explicitly given to him for the period. Tom must still be accountable as himself for his actions when acting in this restricted way for Jerry. In this example identity "Tom" could be used for "Logon", "Audit", "Charging", "Non-repudiation" and "Privilege Attribute Access" (extended to permit access to access identity attribute "Jerry"), but Jerry would be used for "Access" use. The question now arises: In order to support a reasonable spectrum of real world security policies, how many separate types of Identity Attribute is it appropriate to support in a distributed security architecture? The SESAME answer is: potentially all of them, but the identity used for logging on need not appear other than as a parameter in authentication exchanges. Most of the attributes are optional. The names that have been chosen for the identity attribute types supported in SESAME are as follows: . Authenticated Identity, which is used in an AUC for "Privilege Attribute Access", . Audit Identity, which is used in both AUCs and PACs for "Audit", . Charging Identifier, which is used in PACs for "Charging". The term "identifier" is used in preference to "identity" because the value will commonly be the identification of an account rather than of the individual himself, . Access Identity, which is used in PACs for "Access", . Non-repudiation Identity, which is used in PACs for "Non- repudiation" (though it should be noted that in practice Authenticated Identity needs to be used in conjunction with this). The name used during "Logon" is unsurprisingly known as Logon Name. The term "name" is used to distinguish it from other forms of identity because unlike them it is not stored in certificates, it is simply a name used by a principal as a convenient form of identification. 3.7 Accountability Accountability is a prime requirement for system security. Without it, it is not possible to obtain other than the lowest level of certification in any security evaluation scale. Furthermore, accountability must be provided to the level of granularity of an individual human user. This often clashes with the need to gather together users in groups for the purpose of access control. There are many installations running today in which more than one human user shares the use of a system "user name" so that they can have the same access rights. Typically the audit trails of such installations cannot distinguish between them. SESAME's ability to separate audit and access identities solves this problem, and also permits audit identities to have values that are directly meaningful to a human audit manager without causing conflict with the system-oriented forms which can be more useful for access control purposes. The need for accountability can also clash with legitimate user rights to privacy, as described in a recent OECD report (see bibliography). SESAME offers a solution in which a user can be anonymous to all but the legitimate authority to which he is accountable. This is achieved by allocating an arbitrary numerical value as the user's audit identity, whose mapping onto the real user's identity is known only to the audit authority. 3.8 Access Paths and Delegation In distributed systems, in order to provide a service of a particular kind, a server may need to access servers of other services. For example an initiator may call a print scheduler to schedule the printing of a file. When the time comes, the scheduler may call a print server to print the file, and the print server may then call a file server to obtain the file to be printed. At each stage appropriate access rights must be established. In this example, the print scheduler may also have access rights of its own with respect to the print servers (the print servers may require that requests are made via the scheduler), but the file server may require the original initiator's rights to be presented before releasing the file. With respect to the file server the print scheduler and print server are both using the original initiator's ACI by proxy, acting as delegates for the original initiator. At the same time, en route, the print scheduler is adding its own ACI to provide the authority that the print server needs. Also, distributed systems commonly contain application services that are themselves distributed over a number of physical servers. An initiator accessing such a service may not know precisely which server of the service can support its requests, and may simply make a request on a convenient server, expecting that server to act as its delegate with respect to another server of the service if necessary. This delegation could be repeated until the server that can handle the request directly is found. In some cases of delegation the initiator and final target may both be happy that each delegate simply passes on the initiator's ACI, effectively impersonating the original initiator (at least to the extent that the ACI values themselves permit). This is the simplest form of delegation, i.e. untraced delegation. In other cases a full trace of the route by which the action was performed may be needed, particularly if the initiator's ACI is not sufficient by itself to authorise the action. An initiator may not wish to delegate all his rights, and may also want to restrict the area within which the PAC may be used. For that purpose, applications may be organized in trust groups. An Application Trust Group (ATG) is a set of applications that trust each other not to mislead one another. PACs can be arranged to be valid only within nominated ATGs or for specific nominated targets. An ATG can be defined by the name of a class of targets or one or more attributes of a class of targets. A PAC may contain more than one trust group and subsequent delegation for all or fewer trust groups can be controlled by any delegate; obviously a delegate is not permitted to delegate more widely than specified in the incoming PAC. A further consideration is the application of constraints. In some cases, it may be important that an initiator delegates some of its privileges to a target which can then use them on another target but only under specific constraints, say for a specific action. An example is the debit of some amount of money in order to pay for a specific transaction. The restrictions are not global but apply per target or per ATG. Although not a short term goal, this feature will be implemented by SESAME. In some situations delegation is not appropriate and mechanisms are provided to prevent a PAC from being delegated. 3.9 Primary and Secondary Principals It is a common requirement that a human user's access rights should be able to be tempered according to the physical security of the location from which he is accessing the system. One way of satisfying this requirement is to view the user's workstation as a traced delegate of the user. The workstation is registered as a principal and supplied with the means of authenticating itself. A target receives the user's Initiator ACI linked to the Workstation's Initiator ACI and can modify its view of the former according to the latter. SESAME supports this, but also offers another simpler approach. Since the user's access to the PA-Service is also via the same workstation, it can be arranged that the PA-Service will know what the workstation's access privileges are at the time the user obtains his own Initiator ACI, and can directly modify values it supplies as policy dictates. This has the advantage that only one PAC is needed in subsequent target accesses, and unless other principals are involved as traced delegates there is no need to enter the complexities of traced delegation in order to handle workstation security issues. The security of a workstation can be assessed only if it can be authenticated, i.e. it is a principal of the distributed system. Following the terminology of ECMA, the workstation (or at least the part of the workstation responsible for authenticating it) is known as the Primary Principal, the user himself being known as the Secondary Principal. Note that the "user" may be an application executing in an end- system. So a Primary Principal represents the security environment in which a Secondary Principal is operating; its Privilege Attributes are those of that environment. A Secondary Principal possesses Privilege Attributes that are independent of the environment in which it exists, but its ability to obtain its Privilege Attributes may be affected by the Privilege Attributes of its Primary Principal. 3.10 Cryptography and Key Management Security in distributed systems relies on the use of cryptographic techniques for preserving the integrity and confidentiality of data during transmission and storage. Integrity protection prevents data from being modified in an undetectable manner, and confidentiality protection prevents data from being read by unauthorized people. Three kinds of cryptographic algorithms are used by SESAME: . symmetric algorithms where the same key is used to encrypt (i.e. confidentiality protect) and decrypt the data, or to seal (i.e. integrity protect) the data and verify the seal of the data. The basis of these algorithms is that a single cryptographic key is involved: a secret key. These algorithms are used in particular to protect the communication exchanges, either for integrity protection or confidentiality protection. . asymmetric algorithms where a different key is used to encrypt or sign data from that used to decrypt or verify the signature of the data. The basis of these algorithms is that two cryptographic keys are involved: a private key known only to its owner, and a public one which can be known by everybody. These algorithms are used in particular to achieve data origin authentication and data integrity of PACs and AUCs. They are also used for inter-domain key distribution. . one-way algorithms where it is possible to encrypt the data but where reconstructing the original data from the encrypted data is computationally intractable. These algorithms may or may not involve the use of a secret key. SESAME uses one-way algorithms but with no secret key. The algorithms are used in the support of control over the use of Privilege Attribute Certificates (PACs) and Authentication Certificates (AUCs), in the handling of authentication by password, and for key distribution. SESAME has been designed and developed so that algorithms can be easily replaced according to local legislation or emergence of a better algorithm in the future. The process of installing cryptographic keys and managing their use is called Key Management. In most real systems it is not practical to store at each principal all of the keys of the other principals it may wish to communicate with. Instead each principal is informed of the key of a Key Distribution Service, which knows the long term keys of the other principals in its domain. The Key Distribution Service is then used by each principal to agree on a dynamically generated short term key with which they can communicate. For the distribution of keys between domains public key technology can be used, each Key Distribution Service that supports inter-domain communication being supplied with a private/public key pair. SESAME supports such a Key Distribution Service. 3.11 Certificate and Certification Authorities, Public Key Technology Certificates and Certification Authorities are used when public key technology is involved. In a large distributed system it is not possible for every principal to know every other principal's public key, but this problem can be overcome by the introduction of an authority, trusted to guarantee the public key of a principal (either an initiator or a target). The guarantor may have a public key of its own which is further guaranteed by a second guarantor and so on. Guarantors are known as Certification Authorities (CAs). A CA is responsible for the production of certificates containing public keys so that anybody who trusts the CA can check a signature produced by an entity whose public key is known; it is also responsible for producing signed revocation lists to enable users to ensure that a certificate is still valid. When a CA has produced a public key certificate and revocation list, they are placed in a distributed service whose role is to make their values widely available. This service is a name service such as a CCITT X.500 standardized Directory. The CA has no further responsibilities; it can therefore operate off-line since the public key certificates and signed revocation lists themselves contain the information needed by its clients. In contrast, the Directory's role is to ensure high availability of the certificates and lists and must be on-line, but it does not need to be trusted for the integrity of the information since it is signed. It is not feasible for a single CA to guarantee all the public keys of principals all over the world, thus several CAs will exist in practice. Usually there would be one CA for one organizational unit such as a company or a site within a company. The certificates used in SESAME conform to the ISO 9594-8/CCITT X.509 Recommendation. SESAME supports two Certification Authority schemes: one suitable for the short term where a small number of CAs will be involved and one for a longer term where a hierarchy of CAs may be needed. When a small number of CAs is involved, it is reasonable to ask that the names of the CAs and the values of their public keys be directly known whereas when a large number of CAs is involved, CA hierarchies and cross certificates between CAs need to be considered. A cross certificate is a certificate of a public key of one CA produced by another CA. This is illustrated in the following example: There are two security domains, Domain 1 and Domain 2. Each domain has its own Certification Authority CA1 and CA2. When CA1 trusts CA2, it certifies CA2's public key, thus anybody in Domain 1 can be sure of the correctness of the public keys of principals in Domain 2, by first getting the public key of CA2 (certified by CA1) and then checking the certificate of a Domain 2 principal produced by CA2 using its public key. By doing this, everyone has to know only one CA's public key. Note that CA2 will not necessarily trust CA1. 3.12 Cryptographic Issues In several countries of the world the use of cryptography is subject to government control, particularly in relation to the hiding of information by enciphering it. Certificates and tokens used by security architectures, such as SESAME's AUCs and PACs, require only integrity protection to make them able to fulfil their purpose securely, and it is therefore important that a security architecture does not require encipherment of these values, or of any other values, except as an optional feature for those systems in which confidentiality of the token values is also important. Cryptographic algorithms and techniques can be subject to patents (RSA for instance) and this can either result in extra costs due to royalties or can cause some of the components of a distributed system to be unable to use that algorithm because their owner does not possess a licence. Therefore a high level of choice of use of cryptographic mechanism is necessary both in terms of algorithm, mode of use and strength of key used. The SESAME architecture has been designed to address these problems. The use of confidentiality is kept to a minimum. It is provided only where it is an essential function (for example in some key distribution protocols it is necessary to encipher the key being distributed). AUCs and PACs are integrity protected, not enciphered. When encipherment of user and system data is a local security policy requirement, SESAME allows the algorithms and keys used to be separately specified, permitting them to have characteristics acceptable to the prevailing political environment. Public key cryptography is used for PAC protection, but the cryptographic support functions have been designed so that the algorithm used is plug- replaceable. Since only integrity protection is needed, an algorithm like NIST's Digital Signature Algorithm can provide the necessary functionality as well as RSA. Use of public key cryptography for key distribution is an option. 3.13 Secure Conversations and Secure Association Contexts When an initiator passes evidence of its access rights to a remote target it is not sufficient just to form an unprotected communications connection, send a PAC then send an access request, expecting the target to know that the request has come from the same initiator as the PAC. A security architecture must provide a means of enabling one or more actual access requests to be securely associated with those rights. SESAME does this using secure conversations, a link being established between the cryptographic key used to protect access requests and the PAC. Details of how this is done are given later in this document. This key needs to be agreed between the parties involved, and the process of installing, generating and establishing mutual knowledge of an agreed key is known as key management. SESAME allows, in theory, any kind of key management scheme since it is handled independently of other aspects of the system (including PAC handling). For smaller domains, key management using only symmetric, secret key techniques may be appropriate, whereas for larger domains, public key technology may be better suited. Mixed schemes are also catered for where, for example, secret key technology will be used within the security domain of the initiator and public key technology will be used in the security domain of the target. The final choice is the customer's, although the choice may also be dictated by law, since patents apply in some countries but not in others (see Section3.12). Once a key has been established between two parties, it is associated with security information such as the PAC to which it is linked, expiry information, and information about how the key is to be used. Security information associated with such a key is the key's (or the conversation's) Secure Association Context. SESAME provides an initiator with the means to modify the secure association context associated with a conversation (subject to security policy constraints). In particular the access privileges of the associated PAC can be subsetted. 3.14 On-line versus Off-line Security Servers The advent of cryptographic public key technology has led to the design and development of systems in which certificates, signed by off-line trusted authorities, can be used to verify the integrity and provenance of information. Such certificates cannot be undetectably tampered with and can be safely held anywhere in the system. They can be validated by any component that knows the public key of the authority that signed them. This makes it possible to design distributed systems in which the authentication of principals and procurement of their Initiator ACI can be performed directly by each target without having to have on-line trusted services like Authentication or Privilege Attribute Services. There are however some disadvantages: . security information about principals in the system will almost entirely be held in the form of certificates and the public keys of the off-line authorities that have signed them. Typically there will exist a number of copies of a particular certificate or public key. Management of change to this security information can therefore become difficult since it is spread across multiple end-systems of the distributed system. It is difficult for example to revoke a principal's access rights or an off-line authority's authority in a sure and timely manner. Instant revocation is particularly difficult, . there is no central management of which principals are currently "logged on" and what access privileges they are using, as there is no concept of logging on to the system as a whole. In general, the approach is more suited to systems in which there is little central management, responsibility for access control being devolved almost entirely to individual end-systems. . the security of the system depends on the privacy of principals' private keys. These keys are not memorable by human principals so they must either be given a portable device containing their private key, such as a smart card, or their private key needs to be held in the system and passed to them following presentation of other authentication information such as a password. In the latter case this represents a form of on-line authentication service, though it can be arranged that such a service does not require the same amount of trust as a more conventional one, . it is difficult to hide from public view the contents of the certificates. It is therefore difficult to provide any confidentiality of a user's identity or of what the user's potential access privileges are. . all components of a system implementing the architecture need to be able to support public key cryptographic operations, . such an architecture cannot be freely implemented world-wide since in some countries a licence is required for use of public key technology in this way. SESAME uses on-line security servers, taking the view that in business some form of overall management control is important. At present SESAME uses public key technology to sign certificates in the form of PACs (and optionally AUCs). However support of public key operations is mandatory in only two of the components (the PA-Service and the PAC Validation Facility described later in this document). Also, as mentioned earlier, a version of SESAME which does not mandate the use of public keys has been developed for integration into OSF/DCE. 3.15 Security Policies and Security Domains As defined in ISO/IEC CD 10181-1, a security domain is a set of elements, a set of security relevant activities and a security policy under the responsibility of the same authority. A security policy may be interpreted at the engineering level as a set of security rules (see ISO/IEC CD10181-1 for more information about these concepts). Large security domains might be organised into sub-domains where all the rules of the upper domain apply and where more restrictive rules or additional ones may also exist. Typically a company might be a security domain, and a site of the company a sub-domain. Also, one overall authority may be partitioned according to the activity being controlled. Authorities in SESAME are the Authentication Authority, the Access Control Authority and the Key Management Authority; the elements are the various security services and the principals (both initiators and targets) that they control. For an initiator to be accepted into the system it needs to be provided with a means of authenticating itself; humans obtain initiator authentication information, such as a system identity and a password, from a human authority. For validation of this authentication information the human authority is represented in the system by an Authentication Service. Application initiators have system equivalents of the authentication information, the password typically being replaced by a cryptographic key. For a target to be accessible, it also needs to have a name and a long term cryptographic key associated with it. The authority supplying this key to a target is the Key Management Authority, the keys being installed by management action. For verification and use of these keys there are two different system representations of this authority: Certification Authorities (CAs) which are off-line, as described in Section 3.11, and Key Distribution Services (KDSs) which are on-line. In theory, a target could be given different keys from different authorities. However, in practice, either a public key pair will be assigned by a CA or a secret key will be assigned by a KDS. A SESAME target is not, in general, associated with a particular Privilege Attribute Authority because a target may be able to recognize directly more than one Privilege Attribute Authority. 4 SESAME DESIGN 4.1 Security Over an Insecure Network SESAME assumes that the network used between the initiator and the target is insecure and so uses cryptographic techniques to preserve the integrity and where necessary the confidentiality of its security control data. The approach has been to minimise the use of encipherment by ensuring that it is used only in the most appropriate places, such as the protection of keys. All security control data exchanged is protected against modification by tamperproof sealing. In addition however, any user data may be optionally confidentially protected when requested by either the initiator or the target. 4.2 Initiator Machine Architecture Initiators use computers to support their interactions with the rest of the system. The initiator's machine can be sub-divided into three main components: the Subject Sponsor, the Authentication & Privilege Attribute Client (APA-Client) and the initiator's half of the Secure Association Context Manager (SACM) - the other part being in the target machine. When the Secondary Principal being sponsored is a human user, the Subject Sponsor is particularised using the term User Sponsor. The initiating machine is represented by the Subject Sponsor, which may or may not itself be authenticatable. The Subject Sponsor in this context is known as a Primary Principal. Thus Primary Principals sponsor Secondary Principals to the system. Section 3.9 has given some of the background rationale to these concepts. A User Sponsor is responsible for providing the user's interface to the system and organising his relationships with the various security facilities before, during and after the use of applications. Its main features are: . to provide the user interface for the user to logon to the system via a range of authentication methods such as passwords, badges or smart cards. It communicates (via the APA-Client) with the A-Service to authenticate the user, obtains the required AUC and establishes cryptographic keys shared with A- and PA-Servers, . to provide the user interface for other security functions utilising A- or PA-Services, e.g. get or change security attributes during a user session, change passwords or logoff, . optionally, to initiate selection of applications for the user to run. This may include accessing a directory or similar service, on behalf of a user, to obtain information about security requirements of the applications the user chooses, . to establish a secure association context with target applications via Secure Association Context Manager, and subsequently call on them. Applications accessed from the User Sponsor may or may not be collocated with it, . monitor the user session to check if the terminal has been inactive for a period defined by the security policy and to take appropriate recovery actions (for example: ask for re-authentication, ask for close down of applications, inform other security services of the terminal inactivity), . if a conversation with an A- or PA-Server is terminated in the normal course of events, for example following a user log off, any secure association contexts and conversations established on the basis of certificates obtained through the closed conversation are also expected to be closed, and associated copies of certificates held in the initiator machine destroyed. If an abnormal (recovery) termination occurs the User Sponsor is further expected to transmit to the affected targets the fact that the termination was abnormal, with the implication that appropriate recovery action should be taken in the target system. If delegation is being performed cascade effect now occurs, with each target passing on the bad news to the next. If an A- or PA-Server revokes an AUC or a PAC, this is expected to have the same effect as a recovery termination, but confined only to targets with which the AUC or PAC in question has been used. A Subject Sponsor sponsoring an application provides the first and last of these functions, the first being oriented towards an application's requirements rather than a human's. The Secure Association Context Manager (SACM) is responsible for initiating the call on the application or on the specific or standard client (e.g. terminal emulator) needed to call on a completely remote application. For client/server applications, the client will again call on SACM to associate with the server part of the application. SACM is responsible for obtaining a suitable PAC either by using the one deposited with it by the APA-Client or by calling on the PA-Service to get an appropriate one or, more rarely, refine an existing one. It is also responsible for obtaining keys and building keys (see Section 4.6). The Authentication and Privilege Attribute Client (APA-Client) hides both the location and type of Authentication and Privilege Attribute Services. As far as the Subject Sponsor is concerned, there may be separated or collocated A- and PA-Servers and these may themselves be collocated with the Subject Sponsor or not. The APA-Client also hides whether logging on using distant A- and PA-Services is done by relaying the dialogue via a more local one or directly. It also deposits AUCs and PACs with the initiator SACM. The APA-Client is responsible for locating A- and PA-Server(s) and connecting to them. The SESAME architecture provides options about how this should be done. However, all cases require the name of the local A- and PA-Servers to be installed into the Subject Sponsor. When the Subject Sponsor itself needs to be authenticated it is done at initialization time, and always with a local A-Server. For locating the appropriate A-Server for a human user, different cases need to be considered depending on whether the user logs on away from his "home" security domain or not. When the user logs on away from home two different scenarios are possible : relaying or referral. Relaying means always connecting to the local A- or PA-Server which is then in charge of forwarding the operation to another A- or PA-Server either able to accept the operation or to forward the operation on again. The process continues until the home A- or PA-Server is reached. It is up to each Server to locate the user's home Server(s) using the extended name provided by the user. The first part of the logon name is taken as a naming domain and the A- and PA-server(s) are identified using this, the local A- or PA-Server has a table of naming domains it can contact and the name of a A- or PA-Server(s) for each. Referral means connecting directly to the appropriate server. If only the last part of the logon name is given by the user to the User Sponsor, the user is assumed to be at home so is assumed to be registered with the local A- and PA-Servers. If the full logon name is given, the hierarchical structure of the logon name of the user is used to identify the home security domain of the user and then the appropriate server(s) of this security domain. 4.3 Authentication A SESAME principal authenticates to the A-Server at which it is registered, though this may be via relay as described above. In its first implementation, SESAME uses a single authentication method that is password based. The authentication method is extensible to support the future implementation of authentication techniques using smart cards. The method makes use of unique numbers (see ISO/IEC DIS 10181-2) to protect against the threat of replay attacks. The SESAME unique numbers are a sequence of a date, a time and a random number. The exchange AI is built using one-way functions. The first one-way function combines the logon identity with the password of the principal, the second combines the output of the first one way function with a unique number and the name of the A-Server. The result is sent over the communication line. This has several advantages: . the A-Server only stores the output of the first one way function and therefore the plain text value of the password is not known to it, . it is not possible for an attacker to detect whether two principals have the same password by scanning the information stored by the A- Server, . no use of reversible encipherment algorithms is needed since the same kind of computation is made on both sides, . the use of a unique number instead of a challenge saves one (or more) exchanges, and . associated with the name of the A-Server provides replay protection against another A-Server from the same Authentication Authority. The overall protection obtained is identical to the protection obtained through the use of challenges, . there is no need to have close synchronization of clocks since a time window is used by the A-Server to record the latest unique numbers recently accepted (e.g. during a five minute time window). When authentication is successful, a conversation key is established between the A-Server and the principal. This key is derived from the authentication exchange and used to protect future exchanges between the initiator and the A-Server. The manner in which the conversation key is established depends upon the authentication mechanism used. The conversation key is computed using a third one-way function which is different from, but uses the same inputs as the other one-way functions. The conversation key is used to integrity protect the conversation and to encrypt other keys when necessary. An optional Confidentiality Dialogue Key (the use of the term "dialogue" here is explained in Section 4.6) may also be established. It is a one- way function of the conversation key. Note that the legislation in force may request that the size of the confidentiality key to be limited. This mechanism ensures that knowledge of the Confidentiality Dialogue Key does not reveal the value of the conversation key. Once authentication is completed, a secure association context (see Section 3.13) is established with the A-Server. The A-Server additionally returns an Authentication Certificate (AUC) in case the authenticated initiator needs to obtain Privilege Attributes from a PA-Server that is not collocated with the A-Server. The AUC contains proof of authenticated identity, an indication of the strength of the authentication and information to control how the AUC is subsequently used. The context established with the A-Server can also be used directly to establish another with the PA-Server when both servers are collocated; in this case, although the AUC values are always needed, if no other PA-Servers are required to be accessed the AUC need not be signed. The authentication level, corresponding to the authentication scheme used, is recorded so that later on privileges can be granted according to this authentication level. The AUC plays a role similar to the TGT in OSF DCE, but in contrast to the TGT, it is transferred only after the authentication has taken place (preventing off-line attacks via the client system). In addition to authentication, other functions are supported by the A- Service. The most important functions, besides log-off which closes the conversation, are those that change the verification AI (i.e. the password in the first implementation) and provide keys to protect communications between the Subject Sponsor and PA-Servers. In summary the A-Service : . authenticates Primary and Secondary Principals, . is able to support several authentication methods, . keeps a record of which principals are logged on to the system, . supplies a shared secret key for use between the Subject Sponsor and the A-Server for use in further requests to the A-Server, including logoff, . supplies shared secret keys for use between the Subject Sponsor and PA-Servers (it may use a Key Distribution Service to help it do this), . produces an AUC for use with a PA-Service, . audits all security relevant events that affect the A-Server, . supports the change of the verification Authentication Information, (e.g. a password ) by users, . is able, when it does not know a particular Secondary Principal, either to relay the request to another A-Server or to find the address of an A-Server, where the principal is likely to be known and return this address to the APA-Client. For each principal, its A-server knows a default PA-Server where the principal is known. The A-Service is able to establish secret keys with PA-Servers. For that purpose, it may directly share secret keys with the PA-Servers or involve a KDS. Authentication of a Primary Principal would normally happen before the authentication of its Secondary Principal takes place. Primary Principal authentication will be required when the security policy restricts certain actions to be performed only from given secure workstations or locations. It should be noted that authentication occurs between the principal and the A-Service and therefore the method of authentication may be changed without affecting the protocol between an initiator and a normal application target, which is always PAC based. 4.4 Acquisition of Privileges A principal's access rights are known as access privileges. These are stored in the form of Privilege Attributes in a PA-Service. The responsibilities of a PA-Service are: . to manage principals' privileges, . to deliver SESAME PACs describing client principals' privileges and their usage restrictions on request of the client, . where security policy requires it, to temper the contents of a Secondary Principal's PAC depending on the Primary Principal from which it is accessing the system, using the Primary Principal's PAC (or its inability to provide one) as input information, . to audit a selectable set of the actions performed, . to provide cryptographic keys, obtained from a Key Distribution Service, for use by its clients to communicate with application targets, wherever the target is, . to provide Public Key Certificates of principals, or Public key certificates of KDSs or Certification Authorities (CAs), obtained from a Directory (or directory style) service, . to check PACs for revocation on request (see "Check Back" at the end of Section 4.7.3), . on being presented with a valid PAC, to provide a "refined" PAC containing less privileges or more usage restrictions than the offered PAC. Once a principal has been successfully authenticated by an A-Server, it contacts a PA-Server to obtain a Privilege Attribute Certificate (PAC), which describes the principal's privileges. The principal provides: . always, either an Authentication Certificate (AUC) and associated communications key information in the form of a key package (see Section 4.6), or a secure association context identifier (obtained from the A-Server when it is collocated with the PA-Server or already established by means of an AUC). This proves the principal's identity and indicates the level of authentication, . optionally, an Attribute Set Reference parameter (see below) to indicate in broad terms the required contents of the PAC, . optionally, a specific list of Privilege Attributes required to be put in the PAC, . optionally, information about the scope of use required for the PAC. For example the Application Trust Groups (see Section 3.8) for which it is to be valid, and its delegation characteristics. Section 4.7 describes all of the PAC controls that are supported. The Attribute Set Reference parameter is a parameter that allows the user to tailor the set of privileges and controls which will be included in the PAC depending on the application(s) that he wants to use. This parameter can be a role name either defined by the administrator or defined by the principal itself. Section 3.5.1 described the use of roles in SESAME. An initiator does not have the ability to generate keys for securing information exchanges with a target end-system. Thus the PA-Server may provide the PA-Client with keys. The PA-Server does not itself perform the functions of a KDS but it interacts with one or more KDSs and/or the Directory to provide keys. To this latter end the PA-Server supports a Directory User Agent function. The request that is used to obtain keys (Get-Key) contains the name of the target. The Get-Key response provides the requested key in two forms: encrypted for the PA-Client under the client/PA-Server conversation key, and packaged in a form that can be directly forwarded to the target. Details are given in Section 4.6. 4.5 Target End-system Architecture The security properties of associations with target applications are handled at the target end by the target component of Secure Association Context Manager (SACM). The relationship is shown in Figure 1, where the links between the target SACM and the target applications it is handling is local and assumed to be secure from tampering. The PAC Validation Facility (PVF) is a trusted piece of code used by the target SACM. Its primary role is to check that the PAC is valid, has arrived in an authorised manner and is intended for an application for which the PVF is responsible. It also provides the application with the keys it will need to communicate with its remote client. The PVF may or may not be collocated with the SACM(s) of the applications it supports. When it is collocated, no specific security measures are needed to secure the communication path between the PVF and the SACM while, when it is distant, additional protection may have to be provided. +-----+ | PVF | +--+--+ | +--------------+ +----------+ Remote +--+---+ +-+------------+ | |INITIATOR |--------------+ SACM +---+ TARGET | | +----------+ Link +------+ | APPLICATIONS |-+ +--------------+ Figure 1. Relationship Between Initiator, Target SACM, PVF and Target Applications Specific properties and responsibilities of PVFs are as follows: . each target application is associated with one and only one PVF via its SACM. More than one application may be associated with a given PVF. Typically there could be one PVF per end-system, supporting all of the applications of this end system, . an application's SACM uses its PVF to validate PACs, to extract and return the information in the PAC that is applicable to this application, to obtain the key under which its conversation with calling system can be protected, and to provide the information and support needed to perform delegation operations with the PAC. An application is not conscious of these uses, it does not directly see the PVF, but is able to ask the SACM for the security information that has been provided by the PVF, such as what access privileges are currently applicable, . PVFs of applications in the same Application Trust group (ATG) (see Section 3.8), are trusted not to spoof or otherwise mislead each other in respect of operations authorised under that ATG. No such trust is assumed across different ATGs, and a PAC issued for use in one ATG cannot be used by its recipients in another unless explicitly authorised by the original initiator. Following successful validation the applicable contents of the PAC are translated, as appropriate according to local security policy, into the local representation of access control values in the target machine. The execution environment of the application process is then established for that application, using whatever local access control values that have been established as needed (for example the process may run under a local user identity obtained by being mapped from an incoming global identity). An off-the-shelf application running in the target machine need know nothing about the SESAME environment that is providing it with protection. It sees no difference from a situation in which the user has logged on directly to the local machine. If an application is aware of security, and wishes to police access requests using controls over and above any that might have been imposed by the underlying operating system, it can ask its SACM for the secure association context information that currently applies. This could be a combination of the local values produced from the mapping of incoming values, and the unmapped incoming values themselves. The application can also find out about control information such as PAC delegation conditions. The API used for this is an extended version of the Generic Security Services API (GSS-API) defined in the August 1992 Internet Draft from the Internet Common Authentication Technology Working Group, which has widespread acceptance in the security community. 4.6 Key Management The exchanges between the initiator and target SACM components are secured using symmetric cryptography based on secret keys. A two level key scheme is used in which a distinction is made between Dialogue Keys and Basic Keys. A Dialogue Key is a temporary key established between the initiator and target SACMs to be used for protecting the part of the conversation that takes place subsequent to the transmission of the PAC. Separate Dialogue Keys can be established for integrity protection and for confidentiality protection, enabling different strengths of mechanism to be applied to conform with local regulations. Dialogue keys are constructed from a Basic Key, which is a temporary (but possibly longer lived as described below) key established between the calling SACM and the PVF of the target application. The Basic Key is used for protecting the PAC and associated PAC control information in transmission. The target SACM never learns this key. The distinction between dialogue and Basic Keys enables the PVF to control whether dialogues between the initiators and targets can take place. Only if the PAC is successfully validated by the PVF will the Dialogue Key(s) that the initiator SACM is expecting to use be released to the target SACM. The distinction also results in the protection of this dialogue being performed independently of the protection of the establishment of the PAC. In the extreme, it is possible to use cryptography for the PAC exchange, and use no subsequent Dialogue Keys at all, with consequent performance benefits at the expense of security. This is a trade off that might be appropriate in systems with only a low level of security requirement, or with communications links that are otherwise protected. Even in such systems, Basic Key protection of PAC exchange is still likely to be required, since without it the threat of (and potential damage from) PAC theft both from off the wire and from within untrusted end-system components is so much greater. A variety of key distribution schemes can be supported for establishing Basic Keys depending on the cryptographic technology available and on the long term keying information held by the parties involved. Subsequent generation of Dialogue Keys is unaffected by this choice. The scheme below is described in terms of a SACM of an initiating system accessing a normal application target end-system using a Key Distribution Server (KDS). In the description, when an initiator accesses a KDS it should be understood that this is always through a PA-Server, however for the sake of brevity , this will not be expanded upon. At an abstract level the PA- Server/KDS combination is referred to as a Trusted Third Party (TTP) since it is trusted by both the client and the target. The fact that the KDS is hidden behind the PA-Server has the advantage that the relationships between it and the PA-Server are unknown to the initiator, and thus may change without affecting it. Note however that the scheme described is in fact also used for distributing keys to PA-Servers themselves, the KDS in this case being hidden behind an A-Server and the target becoming a PA-Server. PVF and application components. +--------------------------------+ | Trusted Third Party | | +------------+ +---------+ | | | | | | | +----------------|-| PAS |---| KDS | | | | | | | | | | | +------------+ +---------+ | | +--------------------------------+ | | + - - - - - - - - - - - - - - - - - - - - -+ | | +------------+ | | | PVF | T A R G E T | | +------+-----+ | | | +---------------+ +-----------+ | +------+-----+ +--+------------+ | | | Initiator | | Target | | | | | SACM |--------+--| SACM +-----+ Applications | | | | | | | | +--+ +-----------+ | +------------+ +---------------+ | | | + - - - - - - - - - - - - - - - - - - - - -+ Figure 2: Logical Components Involved in Key Distribution Whatever the key distribution protocol, the target system receives its key distribution information under the protection of one or more long term keys installed by management action. A target application's long term key is held by the PVF. The key may be unique to the application or it may be a single key shared between the applications it supports, substantially reducing the number of keys that have to be managed. In either case the PVF is trusted to manage the key or keys on their behalf. SACMs wishing to establish a Basic Key do not see this distinction, believing that each application has its own key. Depending on the technology supported, the long term key could either be a secret key shared with a KDS or could be a private key of a public/private key pair. A KDS may need to communicate with other KDSs in order to complete the distribution of a Basic Key. For this purpose it may either have a private key of a public/private key pair or share a secret key with the other KDS. 4.6.1 Basic Keys The Basic Key is established between an initiator's SACM and a target PVF for presenting PACs to the PVF. If the PACs for the same principal can be used by the same initiator for accessing different applications supported by the same PVF, there is no need to establish further Basic Keys. The different application dialogues will be conducted under the protection of different Dialogue Keys, preventing interference between them. A Basic Key may be constructed either by requesting it from a Key Distribution Service or by the initiator SACM building it locally. The first option, illustrated in 1) below, is always possible and it is therefore the first method supported by SESAME. The second, illustrated in 2) below, will only be possible later when public keys are used everywhere. 1) When the SACM requests a Basic Key from the Trusted Third Party (TTP) it receives back two pieces of information: . a Basic Key encrypted under a key already shared between the SACM and the TTP, . a Basic Key package valid for the specified target application. The overall exchange is protected under the key shared between the initiator SACM and the TTP. The SACM does not need to understand the content of the Basic Key package but simply forwards it to the target SACM which passes it on to the PVF. This gives some flexibility over the different schemes which may be used while keeping the initiating machine unchanged. 2) When the initiator is prepared to build keys itself and when the target application's long term key is a private key, a Basic Key may be established directly without a KDS. Different Basic Key packages supporting different configurations have been identified. For example: . Single KDS involved: the target shares a secret key with the KDS. . No KDS involved: the target has a private key. . Two KDSs involved: they both share a secret key, the target shares a secret key with its KDS. . Two KDSs involved: each of them has a private key, the target shares a secret key with its KDS. The establishment of a Basic Key may or may not involve direct communications between the KDSs. All of these schemes can usefully be optimised for performance by use of caching techniques. 4.6.2. Dialogue Keys A dialogue may only be established after a Basic Key has been established. The Dialogue Key is a key used for a single conversation between an initiator and a target application. Several Dialogue Keys may be derived from the same Basic Key, allowing an individual initiator to have multiple concurrent or consecutive associations for different applications sharing the same PVF. The Dialogue Key is built in such a way that replay protection is provided as part of the key establishment procedure. The security policy in force in a security domain may require confidentiality protection of some dialogues and consequently there may be a requirement for producing keys to achieve confidentiality. However the confidentiality protection may need to have a different strength from the integrity protection and the key used for confidentiality may need to be weaker (i.e. shorter) than that used for integrity. There are therefore potentially two Dialogue Keys: one for integrity and one for confidentiality. The following figure illustrates the different keys that may exist when an initiator accesses a target : Initiator Target +-----------------------+ +-------------------+ | SACM | | PVF | | | | | | Basic Key | Key Packages --> | Basic Key | | | |--------------------| | | | | | +---|---------------+ | | | | | SACM | | +---Dialogue Key | | +--Dialogue Key | | | for Integrity | | | for Integrity| | | (1) | | | (1) | | | | | | | | | | | | | | +---Dialogue Key for | | +- Dialogue Key | | Confidentiality | | for Confid- | | (2) | | entiality | | | | (2) | +-----------------------+ +-------------------+ (1) Derived from the Basic Key (2) Derived from Basic Key to provide data integrity to provide data confidentiality. Figure 3: Basic keys and Dialogue keys One particular method (involving the use of one-way functions with the Basic Key and a unique number as seeds) has been chosen by SESAME to establish the Dialogue Key, since it avoids sending enciphered information from the initiator. Other methods are in principle permitted however, and provision for indicating the method to be used has been made by enabling the initiator SACM to send a Dialogue Key package to the target PVF to indicate the method of construction. A Dialogue Key package contains indications of the Dialogue Key construction method and construction parameters for both the integrity and confidentiality Dialogue Keys, and the name of the target application. The package is integrity protected under the Basic Key. Indication of when the Confidentiality Dialogue Key is going to be used, is made separately from the Dialogue Key package. 4.7 Privilege Attribute Certificates (PACs) This section describes the structure and contents of the Privilege Attribute Certificate, and how the contents are used. Although the descriptions below relate specifically to PACs, many of the features described apply equally well to Authentication Certificates. 4.7.1 PAC Structure A PAC conforms to the definition of a security certificate described in ISO 10181-1. The general form of a security certificate has three components : . information common to all security certificates, . security information specific to one or more security services (in this case: access control), . information to control and/or limit the use of the security information. The information common to all security certificates falls into three categories: . information that uniquely identifies the certificate, . information that provides both integrity and data origin authentication, i.e. a cryptographic check value and indications about the information to be used to verify it. Since the data origin authenticated is that of the issuing authority, the identity of the authority and the identity of the agent that issued the security certificate are indicated. . information from which a period of validity can be either identified (e.g. an explicit validity period) or derived (e.g. a creation time and an implicit validity period). This prevents the indefinite re- use of the security certificate although the security certificate may be re-used several times. The security information specific to access control falls into three categories: . access privileges in the form of Privilege Attributes (e.g. identity, group membership, role, clearance, or capability). Role reflects a particular job function within an organization, as described in Section 3.5.1. A clearance can be used when a labelling scheme applies to the target objects (either sensitivity labels or integrity labels). A capability allows access to be directly granted to an object for a particular type of access (e.g. read, write, execute). The privileges that may be contained in a PAC therefore allow all of the schemes identified in the Access Control Framework (ISO/IEC CD 10181-3) to be supported: ACL based schemes, labelling schemes and capability based schemes, . information specifying the type of PAC and thus the applicability of the privileges contained in it. In particular it indicates whether the privileges are for a Primary Principal or a Secondary principal, and whether in the latter case the Primary Principal's attributes have been taken into account, and whether the attributes are usable only in the context of the principal being a delegate, . identities that can be used for auditing purposes. The information to control and limit the use of a PAC falls into two categories: . information to protect the PAC from unauthorized use, . information to trace the use of the PAC and to be used for recovery purposes. The information to protect the PAC from unauthorized use consists of: . attributes that describe the characteristics of the initiators that can validly submit the PAC, . attributes that describe the characteristics of the target applications for which the PAC is valid, . protection methods and protection parameters to protect the PAC from theft (see Section 4.7.3), . information to control the number of times the PAC may be used, . information to indicate whether receiving targets should revalidate the PAC with the issuing PA-Server prior to accepting it. A group reference that can be used to revoke a group of PACs is provided for recovery purposes, and the unique identifier from the common contents can also be used for this purpose. The SESAME PAC is based on a profile of the ECMA PAC. The ECMA PAC has been designed to conform to emerging ISO definitions of a security certificate and an Access Control Certificate. 4.7.2 Identities The PAC supports the distinction between the different meanings and uses of the identity of a principal by permitting multiple different identity types to be carried. These have been described in Section 3.6. 4.7.3 PAC Controls A PAC supports different kinds of controls over where and when a PAC should be acceptable and who can make use of it. Although all of the controls described below may in theory be present within the same PAC, in practice it is expected that only simple combinations will be used. A PAC is constructed to contain fields identifying which of a number of possible protection methods are associated with it. For each protection method, there are different protection method parameters. The protection methods and their parameters cannot be tampered with because they are integrity protected under the signature of a server of the issuing PA- Service. The construction of the protection methods is sufficiently general to be capable of extension and variation, while maintaining compatibility with existing methods (details of how methods are identified are not given here; the logic of each scheme is not affected by its method of identification). 4.7.3.1 PAC ownership Since a PAC is not encrypted but only integrity protected (signed), nothing would prevent an attacker listening to the communication line and inserting the observed PAC value in its own data flow. In order to prevent a PAC from being used in an this unauthorised manner, the concept of PAC ownership has been introduced, and different kinds of protection methods have been designed to meet different needs. The SSID (Subject Sponsor Identifier) Protection Method This method is used for non-proxiable PACs. At the same time it allows the PAC to be used by the original owner at more than one target. As the PAC is not proxiable, none of the potential receiving targets can pretend to be its owner or act as delegate for its owner. The SSID method controls the use of a non-proxiable PAC by identifying the initiating Subject Sponsor (SS) in the PAC. The method is valid even if the SS cannot authenticate itself. It works as follows: 1) When a given SS (via its SACM) establishes a secure association context for protecting its conversation with an A-Server, the A-Server creates an identifier for the SS. This may be a meaningful name (for example if the SS was able to authenticate itself) or an arbitrary value unique for this SS within this A-Server. In combination with the A-Server's own identity, this forms an Identifier that is unique. The combined value is referred to as SSID. 2) Any Basic Key obtained from a KDS via either an A-Server (to access a PA-Server) or a PA-Server (to access an application target) will have included in the Basic Key Package the SSID value. The SSID value is communicated to the KDS by the A-Server either directly or via the PA-Server. The KDS will only accept SSID values from A-Servers or PA-Servers it trusts. The different key management schemes outlined above all allow an SSID to be associated with any Basic Key Package generated by a KDS. 3) A PAC obtained from a PA-Server will contain, when this protection method is used, an SSID value. 4) When a target receives such a PAC, it will only be accepted by the target's PVF if: . the SSID in the PAC is the same as the one in the Basic Key package used to establish the Basic Key used for protecting the presentation of the PAC, proving that the entity that asked for the PAC is the same one as is now offering it as evidence of its access privileges, and . the KDS providing the Basic Key and the PA-Server providing the PAC comply to the trust conditions of the PVF or of the local KDS of the PVF. In the first release it is required that the KDS providing the Basic Key and the PA-Server providing the PAC must be from the same security domain. CV/PV method. The CV/PV protection method allows a PAC to be proxiable, i.e. passed from the initiator to a delegate and then from delegate to delegate. Each delegate then has the capability of issuing new actions to at least a subset of the targets identified in the PAC by the initial originator. In this method, valid initiators are linked to the PAC by means of one or more Protection Values (PVs) in the PAC, each with a corresponding Control Value (CV). The only initiator that initially knows any CVs is the original requester of the PAC. Each Protection Value is a one-way function of its Control Value. Each Protection Value is associated with an Application Trust Group (ATG) described in Section 3.9 or a directly specified group of targets. The original initiator, and subsequently its valid delegates, prove knowledge of the CV for a particular PV by passing it encrypted under the Basic Key used to protect the transmission of the PAC. Provided that other controls in the PAC permit it, the receiving target can then use the PAC by proxy within the PV's ATG since its PVF knows the corresponding CV. Proxy can therefore be permitted and controlled within an ATG, without the original initiator needing to be aware of the precise identity of the final target application server. It is necessary for the initiator to know only that the final target is in the same ATG as the initial one. Proxy can also be permitted and controlled across ATGs, so long as the original initiator knows the identity of the ATGs that will be needed later. To enable this form of proxy, the initiator provides to the intermediate application in the first ATG a PAC which contains PVs, each one associated with the name of a different ATG. It also provides whichever corresponding CVs the target will need to use the PAC in the ATGs that the initiator wishes to permit. PAC chaining method This control is only applicable to proxiable PACs. It enables the construction of a chain of PACs, with a distinction being made between the first PAC of a chain and other PACs (delegate PACs). This makes it possible to trace the route followed by a given operation. In the PAC chaining method the original owner of a PAC has the ability: . to designate its own PAC as the first of a chain, . to nominate the next delegate. A delegate receiving the PAC has the ability: . to add its delegate PAC to the chain, . to nominate the next delegate. A target receiving the chain of PACs will check that all chain links match correctly starting from the first PAC till the last. 4.7.3.2 Restrictions Associated with a PAC Since a PAC can in general be used with any action, a delegate could modify the original initiator's action or invent its own actions when a proxiable PAC is forwarded. However in some cases, the initiator would like to make sure that some actions cannot be performed by a delegate. An initiator can do this by either specifying restrictions to operations, or tying specific operations to the PAC. The restrictions need not be global but can specify the names of the targets or ATGs where they are applicable. A target's access authorisation functions are expected to police the restrictions. Two methods have been designed to support this requirement. The CK/PK (Control Key/Protection Key ) method The CK/PK method allows a PAC to be obtained in advance, the restrictions being defined later on. In this method the restrictions imposed are prevented from being maliciously modified by means of a Public/Private Key pair under an asymmetric scheme such as RSA or DSA. This key pair is obtained from the PA-Service by the initiator for whom the PAC is being created. The public Protection Key and the algorithm identifier are placed within the PAC while the private Control Key is given to the initiator encrypted on its way from the PA-Service to the initiator. The operations or the restrictions are then signed by the initiator with the private Control Key. Authorization facilities can check the signature using the corresponding public Protection Key which is placed in the PAC. The second method requires that restrictions be defined in advance of obtaining the PAC. The HR (Hashed Restriction) method. In this method the restrictions imposed are prevented from being maliciously modified by placing a hash of the restrictions in the PAC, the restrictions themselves being placed external to the PAC. The hash value is obtained through a one way function and is calculated by the initiator. It and the algorithm identifier are placed within the PAC by the PA-Service on request of the initiator. Authorization facilities can check the restrictions by recomputing the hash value using the algorithm identifier of the one-way hash function placed within the PAC and then comparing this value with the one contained in the PAC. 4.7.3.3 Other PAC controls Three other controls can also be applied to the ways in which a PAC can be used: . The use of a PAC can be controlled by specifying in the PAC, attributes that valid targets for this PAC must possess. . Specific PACs can optionally be controlled in terms of the number of times they may be presented for use at specified targets (using a "Count" field in the PAC). . Instant revocation is also possible (using a "Check-back" field). The Check-back field requires that the target PVFs to which such PACs are transmitted access the issuing PA-Server to check that the PAC is still valid at the time of receipt, in particular that it has not been revoked. This is intended for particularly sensitive operations. It will not be implemented in the first release. 4.7.3.4 Inter-domain access SESAME PACs are signed and so can be presented to any target in any domain that recognizes the signature of the producing PA-Server. Thus the same PAC can potentially be used world wide. It is possible however that individual targets in the receiving domain may not be able to be individually notified of the recognition, or they may not be able to directly understand the Privilege Attributes in the PAC. SESAME solves this problem by providing an Inter-domain Service which can verify PA- Server signatures from other domains and if necessary translate Privilege Attributes. An Inter-domain Service is called into use by target PVFs receiving PACs they cannot themselves validate satisfactorily. The sending initiator does not see the Inter-domain service; it always simply sends the PAC to the target in the normal manner. In this way, if a bilateral agreement between an initiating domain and an individual target PVF manager has been established, use of an Inter-domain Service can be avoided. 4.7.3.5 Representation of Privileges Within a PAC, principals' privileges are represented in a standard form independent of any particular operating system. See Section 3.4. 4.7.3.6 Accountability and Audit A PAC contains an audit identity which is used by the auditing system when reporting a principal's actions to ensure individual accountability. This provides the mechanism to ensure that an individual user, such as a secretary, can work with another individual's privileges, for example a superior's access identity, but still be accountable for all actions through the audit identity. The A-Service can assign an "anonymous value" to the audit identity, different for each logon. This is transferred to the PA-Service to be propagated into PACs issued for the principal concerned. If the access control is for example based on role or capability rather than identity the target will be unable to identify the principal. The principal will however remain accountable for his actions via the audit trail by tracing the true identity hidden behind the anonymous audit identity. 5. COMPARISON WITH OTHER ARCHITECTURES This section offers a brief outline comparison with two other existing distributed security architectures. It contains SESAME information already described in some detail in earlier sections, but highlighted here as part of the comparison with the other architectures. Apart from SESAME, the best known security architectures for distributed systems that have been developed and presented are the security aspects of the Open Software Foundation's Distributed Computing Environment (OSF DCE) which are based on Kerberos from MIT, and the Digital Distributed System Security Architecture (DSSA) from Digital Equipment Corporation, of which the Distributed Authentication Security Service (DASS) is an implemented subset covering only the authentication functions of DSSA. DSSA has a wider scope than the other architectures, encompassing the authentication of software components as they are installed in individual end-systems. It relies heavily on the use of public key technology to do this. DSSA aims to avoid on-line security servers, has no on-line key distribution service and has an identity based access control scheme in which all additional access privileges are pulled from a Directory by targets. DSSA and SESAME make use of both public and secret key technology, whereas OSF DCE uses only symmetric key techniques. DSSA aims for a solution in which all entities, including human users, are associated with a private/public key pair, though the DASS partial implementation of this allows a user to authenticate by means of a password to an on-line A- Service from where the user's private key is fetched. Private/public key pairs are used in DSSA both for authentication and for key distribution. OSF DCE and SESAME make use of on-line security servers (for authentication, obtaining Privilege Attributes and performing key distribution). On-line servers provide for better real-time management, in particular better revocation capabilities but are subject to attack. Both architectures also use the push model, access privileges being sent along with access requests in a form that can be trusted by the target. This is considered to be a better approach when access privileges other than identity are to be supported. The A-Services of DASS and OSF DCE do not maintain state information about their users. In particular they do not record whether any given user is currently logged on to the system or not. SESAME's A-Service does maintain such state information, and by doing this SESAME can keep track of users that are active at any instant, and (if policy requires it) prevent a user logging on twice at the same time. OSF DCE could be extended to incorporate such features, but DSSA does not lend itself to this. Access privileges are supported in OSF DCE and in SESAME, provided via on- line privilege servers. In DSSA all access privileges other than identity are stored in signed certificates in a Directory. An advantage of the DCE/SESAME approach is that privileges are provided according to the requirements of the accessor, obeying the principle of least privilege and supporting anonymous access control. DCE could, whereas DSSA could not, be extended to support anonymous access control as provided by SESAME, i.e. targets need not necessarily learn the identity of an accessor. Revocation is easier since access privileges are managed on- line rather than held in certificates signed by off-line authorities. OSF DCE at present only provides for access privileges in the form of UNIX oriented identity and groups though this can be extended to other UNIX types. SESAME and DSSA both have a wider vision of security attributes suitable for systems of all types. SESAME expressly allows for customers to define their own access privilege types. SESAME emphasises the use of roles for access control on the basis that from a management point of view, practical business security policies will greatly benefit. Accountability needs to be assured by auditing security related events, including access control decisions. All of the architectures are potentially capable of providing such audit trails, though only SESAME provides the ability to separate audit identity from access control. 6. BIBLIOGRAPHY 1. D.D. Clark and D.R. Wilson "A Comparison of Commercial and Military Computer Security Policies", Proceedings of the 1987 Symposium on Security and Privacy, April 1987, Oakland CA, USA. 2. ECMA-138 "Security in Open Systems - Data Elements and Service Definitions", December 1989 3. ECMA TR/46 "Security in Open Systems - A Security Framework", July 1988 4. M.Gasser, A.Goldstein, C.Kaufman, B.Lampson "The Digital Distributed System Security Architecture", National Computer Security Conference, Baltimore USA, 1989 5. E.J.Humphreys (editor) "Taxonomy of Security Standardisation" Version 2.0, 30th April 1992 ITAEGV Report number N69 6. ISO 7498-2 (CCITT X.800) "OSI Security Architecture" 7. ISO/IEC CD 10181-1 "Information Technology - Security Frameworks in Open Systems - Part 1: Security Frameworks Overview" 8. ISO/IEC CD 10181-2 "Information Technology - Security Frameworks in Open Systems - Part 2: Authentication Framework." 9. ISO/IEC CD 10181-3 "Information Technology - Security Frameworks in Open Systems - Part 3: Access Control." 10. P.Kaijser "Secure Open Systems: Some Security Architectures", Computer Fraud and Security Bulletin November 1992 (Elsevier) 11. C.Kaufman "DASS Distributed Authentication Security Service", Internet Draft, October 1991, Common Authentication Technology Working Group 12. J.Linn "Generic Security Service API", Internet Draft August 1992, Common Authentication Technology Working Group 13. OECD: Ad Hoc Group of Experts on Guidelines for the Security of Information Systems, "Recommendation of the Council Concerning Guidelines for the Security of Information Systems, and Explanatory Memorandum to Accompany the Guidelines" Page 24, DSTI/ICCP/ AH(90)21/REV5 August 1992 14. T.A.Parker "A Secure European System for Applications in a Multi- vendor Environment (The SESAME Project)", Proceedings of the 14th American National Security Conference 1991 15. D. Pinkas "An Access Control Model for Distributed Systems Based on the use of Trusted Authorities" Proceedings of the 7th world-wide congress on computer and communications security and protection (p. 257-270, SECURICOM 1989. 16. J.G.Steiner, C.Neumann & J.I.Schiller, "Kerberos: an Authentication Service for Open Network Systems", USENIX Winter Conference 1988, pp.191-201.