SINGLE SIGN-ON IN HETEROGENEOUS COMPUTER ENVIRONMENTS by CECIL PETRUS LOUWRENS DISSERTATION

Transcription

1 SINGLE SIGN-ON IN HETEROGENEOUS COMPUTER ENVIRONMENTS by CECIL PETRUS LOUWRENS DISSERTATION submitted in fulfillment of the requirements for the degree MASTER OF SCIENCE in COMPUTER SCIENCE in the FACULTY OF SCIENCE at the RAND AFRIKAANS UNIVERSITY SUPERVISOR: PROF SH VON SOLMS NOVEMBER 1996

2 2Iecbcated to Aiet, _And and Cornehuo

3 Acknowledgments To my wife Alet, and my children, Anri and Cornelius: This was truly a team effort! I could not have done it without your love and support during the past year. Thank you very much. A special word of thanks to my supervisor, Prof S.H. von Solms. I appreciate your encouragement and guidance during this study. You have taught me much more than just Computer Security.

4 Summary The aim of this dissertation (referred to as thesis in the rest of the document) is to investigate the concept of Single Sign-on (SSO) in heterogeneous computing environments and to provide guidelines and reference frameworks for the selection and successful implementation of SSO solutions. In doing so. it also provides an overview of the basic types of SSO, Secure Single Sign-on (SSSO) solutions, enabling technologies, as well as products currently available. Chapter 1 introduces the sign-on problem, the purpose and organization of the thesis and terminology and abbreviations used. The crux of the sign-on problem is that users are required to sign on to multiple systems, developed at different times and based on different technologies, each with its own set of signon procedures and passwords. This inevitably leads to frustration, loss of productivity and weakened security. Users frequently resort to writing down passwords or using trivial password that can easily be guessed. In Chapter 2 the concepts of Single Sign-on and a special subset of SSO, Secure Single Sign-on are defined. Five types of SSO solutions are identified, namely: Synchronization, Scripting, Proxies and Trusted Hosts. Trusted Authentication Server and Hybrid solutions. Of the available types of solutions, only Trusted Authentication Server and Hybrid solutions can provide Secure Single Sign-on if properly implemented. The security services for SSSO are identified as authentication, authorization, integrity, confidentiality, non-repudiation, security management and cryptographic services. Additional SSSO concepts, as well as the vulnerabilities, obstacles and pitfalls to introducing SSO solutions are discussed. Chapter 3 provides an overview of the most important SSO enabling technologies. The following technologies are discussed: OSF DCE, SESAME, Kerberos, DSSA/SPX, TESS, NetSp, Secure Tokens, GSS-API and Public key Cryptography. Chapter 4 discusses the Open Software Foundation's (OSF) Distributed Computing Environment (DCE). OSF DCE is one of the two open standards for distributed processing which are having a major influence on the development of single sign-on solutions and forms the basis of many existing SSO products. DCE is not a SSO product. but consists of specifications and software. The goal of DCE is to turn a computer network into a single, coherent computing engine. It is considered to be one of the fundamental building blocks for SSO solutions in the future. In Chapter 5 SESAME is discussed in some detail as another major enabling technology for SSO. Secure European System for Applications in a Multi-vendor Environment (SESAME) is an architecture that implements a model for the provision of security services within open systems developed by the European Computer Manufacturers Association (ECMA). The architecture was developed and implemented on a trial basis, by Bull, ICL and Siemens-Nixdorf in an initiative supported by the European Commission.

5 Chapter 6 presents a list of 49 commercial SSO products currently available, classified according to the type of SSO solution. A few representative products are discussed in more detail to give an indication what functionality a prospective buyer could expect. The 'Ideal Single Sign-on' solution is presented in Chapter 7. Detailed requirements are listed. These requirements are uniquely identified by a code and classified as essential or recommended functionality required. Chapter 8 assimilates the information in the previous chapters into a structured evaluation, selection and implementation plan for SSO solutions, consisting of nine separate phases. It also proposes a reference framework for the evaluation and selection process. Chapter 9 concludes the thesis. Findings and conclusions are summarized as to the importance and impact of Single Sign-on as well as the expected future directions to be expected. In addition. recommendations for the future implementation of SSO and SSSO solutions in heterogeneous computing environments are made.

6 Opsomming Die doel van hierdie verhandeling is om die konsep van Enkel-aanteken (Single Sign-on) in heterogene rekenaaromgewings te ondersoek om sodoende riglyne en verwysingsraamwerke te verskaf vir die keuse en suksesvolle implementering van Enkel-aanteken (EA) oplossings. Hierdeur word daar ook 'n oorsig verskaf van die basiese tipes Enkel-aanteken oplossings, Beveiligde Enkel-aanteken (BEA) (Secure Single Sign-on), tegnologiee wat Enkel-aanteken bevorder, sowel as produkte wat huidiglik beskikbaar is. Hoofstuk 1 bespreek die aanteken-probleem, asook die doel en uitleg van die verhandeling, en terminologie en Awnings wat gebruik word. Die kern van die aanteken -probleem is dat daar van gebruikers verwag word om aan te teken na verskeie stelsels, bestaande uit verskillende tegnologiee, elkeen met sy eie stel wagwoorde en aantekenprosedures. Dit lei tot onvermydelike frustrasie, verlies aan produktiwiteit en 'n verswakking van sekerheid. Gebruikers wend hulle dikwels tot die neerskryf van wagwoorde of die keuse van wagwoorde wat maklik onthou kan word, en dus ook maklik geraai kan word. In Hoofstuk 2 word die konsepte van Enkel-aanteken en 'n spesiale subklas van Enkel-aanteken, naamlik Beveiligde Enkel-aanteken, gedefinieer. Vyf verskillende tipe Enkel-aanteken word geidentifiseer, naamlik: Sinlcronisasie, Gevolmagtigte Bedieners (Proxies), Betroubare Bekragtigingsbedieners (Trusted Authentication Servers) en Hibriede oplossings. Slegs die twee laasgenoemde tipes verskaf BEA. indien behoorlik aangewend. Die sekerheidsdienste vir BEA word geidentifiseer as bekragtiging, bemagtiging, integriteit, vertroulikheid, onweerlegbaarheid, sekerheidsbestuur en kriptografiese dienste. Bykomende BEA konsepte, sowel as die kwesbaarhede, hindemisse en slaggate van die implementering van BEA oplossings word ook bespreek. Hoofstuk 3 gee 'n oorsig van die belangrikste EA tegnologiee. Die volgende word bespreek: OSF DCE, SESAME, Kerberos, DSSA/SPX. TESS, NetSp, Veilige Tekens, GSS-API en Publieke Sleutel Kriptografie. Hoofstuk 4 bespreek die Open Software Foundation (OSF) se Distributed Computing Environment (DCE). OSF DCE is een van die twee oop standaarde vir verspreide verwerking wat 'n betekenisvolle invloed op die ontwikkeling van EA oplossings het, en ook die basis vorm van verskeie bestaande EA produkte. DCE is nie n EA produk nie, maar bestaan uit spesifikasies en sagteware. Die doel van DCE is om 'n rekenaametwerk in 'n enkele verwerkingseenheid te omskep. Dit word as een van die basiese boublokke vir EA oplossings beskou. In. Hoofstuk 5 word SESAME bespreek as nog 'n belangrike tegnologie vir die daarstelling van EA. Secure European System for Applications in a Multi-vendor Environment (SESAME) is 'n agitektuur

7 vir die daarstelling van 'n model vir die verskaffing van sekerheid binne oop stelsels wat deur die European Computer Manufacturers Association (ECMA) ontwikkel is. Hierdie argitektuur is op 'n loodsbasis deur Bull, ICL en Siemens-Nixdorf ontwikkel en is deur die Europese Kommissie ondersteun. Hoofstuk 6 bied 'n lys van 49 handelsprodukte aan, wat volgens die tipes EA oplossings geklassifiseer is. n Paar verteenwoordigende produkte word vervolgens in meer detail bespreek en gee 'n aanduiding van watter kenmerke die voomemende koper to wagte kan wees. Die 'Ideale EA oplossing' word in Hoofstuk 7 aangebied. Gedetailleerde vereistes word gelys. Hierdie vereistes word uniek geidentifiseer deur 'n kode en word geklassifiseer as noodsaaklike of aanbevole kenmerke wat benodig word. Hoofstuk 8 neem die inligting uit die voorafgaande hoofstukke en stel dit saam tot 'n gestruktureerde evaluasie, seleksie en implementeringsplan vir EA oplossings, bestaande uit nege fases. Dit stel ook 'n verwysingsraamwerk voor vir die evaluasie en seleksieproses. Hoofstuk 9 is 'n samevatting van die verhandeling. Bevindings en gevolgtrekkings word opgesom wat dui op die belangrikheid en invloed van EA, sowel as die verwagte toekomstige rigtingaanduiders daarvan. Daarmee saam word aanbevelings vir die toekomstige aanwending van Enkel-aanteken en Beveiligde Enkel-aanteken oplossings in heterogene rekenaaromgewings gemaak.

8 Table of Contents INTRODUCTION THE SIGN-ON PROBLEM PURPOSE OF THIS THESIS LAYOUT AND ORGANIZATION OF THIS THESIS TERMINOLOGY AND ABBREVIATIONS Terminology Abbreviations 13 SSO CONCEPTS INTRODUCTION TYPES OF SSO SOLUTIONS Synchronization solutions Scripting solutions Proxies and Trusted Hosts Trusted Authentication Server solutions. ' Hybrid solutions Conclusion SECURITY SERVICES REQUIRED FOR SSSO Authentication and Single Login (Sign-on) Authorization and Logical Access Control Integrity Confidentiality Availability Non- repudiation Security Management Cryptographic Services and Key Management ADDITIONAL SSSO CONCEPTS Security over an Insecure Network On-line versus Off-line Security Servers Heterogeneity of Privilege Attributes Uses of Identity Roles Access Paths and Delegation Security policies and security domains Trusted Third Party (77'P) Components 32 Page 1 of 173

9 2.5 CRYPTOGRAPHY AND KEY MANAGEMENT Algorithms Basic Keys and Dialogue Keys Key Management Cryptographic Issues NEW VULNERABILITIES INTRODUCED BY SSSO Single-point-of-failure Multiplied access: Insecure storage: Insecure transmission: OBSTACLES AND PITFALLS TO BE CONSIDERED Immaturity of Products Lack of experience Uncertainty about Costs and Benefits Scalability Dependence on Architecture Catering for fitture requirements Conformance to Standards Cost of features not required Establishing Single Userids Security Management and Administration Security Certification CONCLUSION ENABLING TECHNOLOGIES FOR SSO AND SSSO INTRODUCTION OSF DCE Standard for Secure Distributed Processing DCE Security Service Public Key Support SESAME SESAME Objective for SSO Use of Public-key Cryptography KERBEROS Secure Authentication Kerberos Tickets Kerberos Security Exposures DISTRIBUTED SYSTEM SECURITY ARCHITECTURE (DSSA OR SPX) Background 46 Page 2 of 173

10 3.5.2 SPX Development Stopped THE EXPONENTIAL SECURITY SYSTEM (TESS) TESS Toolboxes TESS Applications IBM NETWORK SECURITY PROGRAM (NETSP) RACF SECURED SIGNON PASSTICKET Generating the PassTicket SECURE TOKENS THE GENERIC SECURITY SERVICE APPLICATION PROGRAM INTERFACE (GSS- API): Introduction GSS-AP GSS-API Services GSS-API Tokens and Security Contexts PUBLIC KEY OR ASYMMETRIC CRYPTOGRAPHY SUMMARY CONCLUSION 53 OSF DCE INTRODUCTION OSF DCE ARCHITECTURE SECURITY SERVICES Additional Services Distributed File System THE DCE CORE SERVICES' Directory Service UUID Distributed Time Service SECURITY SERVICE Authentication Service Authorization Service Registry Service CONCLUSION 61 SESAME TECHNOLOGY VERSION INTRODUCTION PLATFORMS SUPPORTED GENERAL DESCRIPTION Security over an Insecure Network Authentication and Single Sign-on Pull versus Push On-line versus Off-line Security Servers 66 Page 3 of 173

11 5.3.5 Heterogeneity of Privilege Attributes Uses of Identity Roles Access Paths and Delegation Security policies and security domains BASIC COMPONENTS OF THE SESAME MODEL TRUSTED THIRD PARTY COMPONENTS On-line authorities Initiator Components Target Components TRUST MODEL SESAME'S USE OF NAMES DIRECTORY NAMING CRYPTOGRAPHY AND KEY MANAGEMENT Algorithms Basic Keys and Dialogue Keys Key Management Cryptographic Issues SESAME SECURITY SERVERS The Domain Security Server Public Key Management Servers GENERIC COMPONENTS Public Key Management (PKM) Cryptographic Support Facility Audit Facility User Sponsor APA Client Initiator Secure Association Context Management (SACM) Cache Handler External Interfaces GSS-APIs WALK-THROUGH Client Machine Interactions TARGET INTERFACES AND COMPONENTS Target Secure Association Context Manager (SACM) PAC Validation Facility External Interfaces lnterdomain Working Key DisTaratmoN 93 Page 4 of 173

12 Protocols that use a KDS lnterdomain Protocol not requiring a KDS THE PRIVILEGE ATTRIBUTE CERTIFICATE (PAC) PAC Structure PAC Protection CONCLUSION OVERVIEW OF SSO PRODUCTS AVAILABLE INTRODUCTION SYNCHRONIZATION PRODUCTS SCRIPTING PRODUCTS TRUSTED AUTHENTICATION SERVER PRODUCTS HYBRID PRODUCTS MICROSOFT NT/HOST SECURITY INTEGRATION Introduction Platforms Supported Architecture Secured Single Sign-on Data Encryption Security administration Availability Conclusion CA-UNICENTER/SSO Introduction Platforms Supported Architecture Fail-over and Recovery Availability Conclusion CKS MYNET Introduction Platforms Supported Agent based Architecture Single Sign-on Scripts Administration Gateways MyNet Fallback 115 Page 5 of 173

13 6.8.9 Token Support Audit Av.ailability Conclusion ICL ACCESSMANAGER Introduction Platforms Supported General Description Availability Conclusion FIRSTSTEP Introduction Platforms Supported General Description /2/ Features of FirstStep Conclusion IBM SECURE SINGLE SIGN-ON Introduction Platforms Supported General Description IBM Directory and Security Server (DSS)for OS/2 Warp Availability OPEN HORIZON'S CONNECTION Introduction Platforms Supported General Description Security Features Communications Application Program Interfaces Availability Conclusion CONCLUSION THE IDEAL SINGLE SIGN-ON SOLUTION INTRODUCTION AUTHENTICATION / Single Automated Logan (AUTH E01) Support common Password Rules (AUTH E02) 133 Page 6 of 173

14 7.2.3 Support a Standard Primary USERID Format (AUTH E03) Auto Revoke after a number of invalid Attempts (AUTH E04) Capture Point of Origin Information (AUTH E05) Support Sign -on's from Variety of Sources (AUTH E06) Ensure USERID Uniqueness (AUTH E07) Authentication Server should be Portable (AUTH R08) Support Public/Private Key technology (AUTH R09) Support Tokens/Biometrics (AUTH RIO) ACCESS CONTROL AND AUTHORIZATION Differentiated administration Privileges (ACL E01) Default Protection unless specified (ACL 02) Ability to support Scripting (ACL E03) Physical TermitzallNodelAddress Control (ACL R04) Single Point of Authorization (ACL R05) Support Standard Ticket/Certificate Technologies (ACL R06). / Support Maskingl Generics (ACL R07) Allow Delegation Within Power of Authority (ACL R08) DATA INTEGRITY/CONFIDENTIALITY/AVAILABILITY No Clear-text Passwords (DICA E01) / Integrity of Security DB(s) (DICA E02) Failsoft Ability (DICA E03) Inactive User Time -out (DICA R04) Commercial Standard Encryption (DICA R05) / Option for Single or Distributed Security Databases (DICA R06) Inactive User Revoke (D1CA R07) Optional Application Data Encryption (DICA R08) Key Management (DICA R09) SECURITY ADMINISTRATION MANAGEMENT AND AUDITING Single point of Administration (SAMA E01) :5.2 Role - profile based (SAMA E02) Full Audit Trail (SAMA E03) Single RevokelResume for All Platforms (SAMA E04) Ability to Enforce Enterprise Security Rules (SAMA E05) Ability to Trace Access (SAMA E06) Scoping and Decentralization of Control (SAMA E07) Synchronization Across all Entities (SAMA E08) Real-Time and Batch Update (SAMA E09) Customize in Real -time (SAMA El 0) User Defined Fields (SAMA El 1 ). 139 Page 7 of 173

15 Support Customized Reporting (SAMA E12) Support User ExitslOptions (SAMA R13) Customizable Messages (SAMA RI4) Common Control Language Across All Platforms (SAMA R15) Ability to Recreate from Logged Information (SAMA R16) Administration for multiple Platforms (SAMA R17) Ability to Create Security Extract Files (SAMA RI 8) Test Facility (SAMA R19) GENERAL FUNCTIONALITY Backward Compatible (GFR E01) Conformance to Standards (GFR E02) Phased Implementation (GFR E03) Scalability (GFR E04) Consistent User Interface (GFR R04) Ease of Use (GFR R05) Flexible Cost (GFR R06) Certification (GFR R07) One Single Product (GFR R08) Software Release Distribution (GFR R09) Compatibility and Itzteroperability with Internet technologies (GFR RIO) CONCLUSION EVALUATING, SELECTING AND IMPLEMENTING SSO SOLUTIONS INTRODUCTION GENERAL CONSIDERATIONS THE STRATEGIC SSO PROCESS PHASE I: AGREE BUSINESS CASE FOR SINGLE SIGN-ON Do Cost-benefit analysis for SSO Prepare Business Case Agree and sign-off Business Case PHASE 2: DEVELOP STRATEGY FOR SINGLE SIGN-ON Identify strategic implications Identify interest and opportunities Agree single sign-on strategy Deciding on the correct type of Single Sign-on solution PHASE 3: AGREE ENVIRONMENT FOR PLOT IMPLEMENTATION 155 _ Determine Criteria for Selection Evaluate Opportunity Areas Select Favorable Environment 155 Page 8 of 173

16 _Single Sign-on in Heterogeneous Computer Environments Confirm with Business Manager PHASE 4: MOBILIZE TEAM Determine range of Experience needed Identify Team Members Fill gaps in know-how with Outsiders PHASE 5: DEFINE THE INITIAL BUSINESS REQUIREMENT Extend initial View of Requirement Assess Target Systems Agree detailed Objectives / PHASE 6: PREPARE SHORTLIST OF AVAILABLE PRODUC I S Send out a Request For Information (RFI) Complete Product Checklist for each product Select most viable products / PHASE 7. SELECT SUITABLE SOLUTION Send out a Request for Proposal (RFP) Select Specific Product Plan pilot implementation PHASE 8: IMPLEMENT PILOT PHASE 9: PLAN AND IMPLEMENT WIDER SOLUTION CONCLUSION 164 CONCLUSION AND RECOMMENDATIONS 165 BIBLIOGRAPHY 168 GLOSSARY OF TERMS TERMINOLOGY AND ABBREVIATIONS TERMINOLOGY 172 /1.2.1 Abbreviations 172 Page 9 of 173

17 Chapter 1 1. Introduction 1.1 The sign-on problem. In the quest to empower individuals for increased efficiency and effectiveness, the prevailing business philosophy is to present users with access to an ever-growing array of information resources. However, few organizations have managed to integrate their information resources into a coherent whole. In most cases, users gain access to the information resources they need to do their jobs via systems developed at different times and based on different technologies, each with their own access control routines. Today's heterogeneous computing environments typically consist of the following platforms to which successive sign-on's must be performed: single- or multi-user operating systems (e.g. Microsoft Windows, IBM OS/2, MacOS, UNIX, IBM MVS) network services(e.g. Novell Netware, the Internet, Intranet) desk-top applications packages (e.g. Lotus Notes) tailor-made application systems business applications packages (e.g. SAP) corporate databases (e.g. DB2, Oracle, Sybase, Ingress).(Stanley, 1996) End users frequently need to access applications and network resources running on multiple platforms to perform their day-to day responsibilities. This typically requires that end users use different sign-on routines, userids and passwords creating a cumbersome management problem for themselves as well as systems administrators and security managers. The same end users often depend on the note-posting technique, trivial passwords or password sharing to contend with multiple sign-on procedures and passwords. (Computer Associates, 1996) Unless measures are taken to streamline the sign-on process, users with access to multiple systems may well be obliged to: master a variety of sign-on processes, each with their own conventions remember a series of different userids and passwords sign-on repeatedly in order to gain access to the range of information resources they need to do their jobs. Repeated sign-on to different systems will be multiplied still Page 10 of 173

18 _Single Sign-on in Heterogeneous Computer Environments further if, for security reasons, users are automatically signed-off from systems after a period of inactivity. (Stanley,1996) Whilst it is vital to ensure that data remains secure, traditional approaches can make systems unusable, requiring users to learn and navigate through different layers of passwords and log-on routines. Current research estimates that usability issues cost the average organization some 10% of the potential productivity gains enabled by IT systems. (ICL, 1996) Gaining access to disparate systems, without single-sign-on (SSO), impacts businesses in three ways : Dissatisfied users: users experience security as a burden and foster an attitude of security being an impediment to performing day-to-day business activities. Reduced efficiency: users can lose significant productive time by multiple sign-on's, changing and maintaining passwords and duplication of the administration effort. Weakened security: faced with the need to remember a series of sign-on data, users are more likely to select passwords that are easily remembered, and thus easily guessed, share them or write them down. (Stanley, 1996) This is clearly a unsatisfactory situation which should be addressed by organizations having problems with multiple sign-on's to heterogeneous computing environments. Single sign-on can help to address these problems. The main goal of single sign-on (SSO) is to eliminate the need for manually signing on to different systems by providing a single, automated process for identifying and authenticating users, which applies to all systems to which they have access. Introducing single sign-on should be a priority in an enterprise where users require access to information resources distributed across the organization. It enhances the way users interact with target systems, improves business efficiency and reduces the risk of unauthorized access to corporate systems and data. However, single sign-on solutions should be introduced with care. They change the way users interact with systems and data: how systems are administered; and the level of security achieved across multiple systems. Choosing the right solution is critical. A wide range of solutions are available, with widely differing capabilities. Some are well proven, while others are new and still becoming established. Each type of solution introduces new vulnerabilities, against which the organization needs to be safeguarded. Page 11 of 173

19 Few organizations have the experience of introducing single sign-on and new types of solutions are emerging, bringing more uncertainty about costs, advantages and possible incompatibilities. The issues above illustrates the need for a document, not only providing information on the subject of Single Sign-on (SSO), but also giving guidance as to the evaluation and selection of products to organizations having to decide on the introduction of SSO solutions. This is the broad purpose of this thesis, as described below: 1.2 Purpose of this Thesis The purpose of this thesis is to: identify the problems and risks created by multiple sign-on's in heterogeneous computing environments; identify and describe the concepts of SSO and Secure Single Sign-on (SSSO); identify and describe enabling technologies; provide a brief overview of commercial SSO products; describe the 'ideal' SSO solution; and create a framework for evaluation and implementation of SSO solutions. 1.3 Layout and Organization of this Thesis This paper is organized into nine chapters: Chapter 1 Chapter 1 introduces the SSO problem, purpose and layout of the paper and terminology used. Chapter 2 In Chapter 2 the generic SSO concepts are discussed. It also introduces the extension of SSO to Secure Single Sign-on (SSSO). Chapter 3 Chapter 3 provides a brief overview of some of the enabling technologies for SSO solutions. Chapter 4 DCE is discussed as one of the two fundamental technologies enabling Secure Single Sign-on. Chapter 5 In this chapter the SESAME is discussed in some depth, as the other of the two fundamental SSSO technologies currently available. Chapter 6 Chapter 6 provides an overview of some of the commercial SSO products available today. Chapter 7 The 'ideal' SSO solution is described in Chapter 7. Chapter 8 By utilizing the requirements as set out in Chapter 7, a framework for evaluating and selecting SSO solutions is presented in Chapter 8. Chapter 9 Chapter 9 presents the conclusion and recommendations for SSO Page 12 of 173

20 single Sign-on in Heterogeneous Computer Environments solutions in heterogeneous computing environments. This is followed by the Bibliography and Glossary of terms and abbreviations. t4 Terminology and Abbreviations Terminology The terminology of the OSI Security Frameworks [ISO 10181] is used where appropriate in this document. In ISO 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 endsystem, though may share it with other servers of different services. The term Directory Certificate is used to describe an extended form of the certificate, defined in the 1993 Directory Authentication Framework Standard [ISO ], that is used to associate an asymmetric cryptographic public key with information about the holder of the corresponding private key (most importantly the holder's distinguished name). In other documentation such certificates are also variously known as user certificates, public key certificates, or X.509 Certificates. (Parker,1995) 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 gender bias intended Abbreviations The following abbreviations are used throughout this document: ACI Access Control Information ACL Access Control List APA Client Authentication and Privilege Attribute (server) Client AS Authentication Server CA Certification Authority CAA Certification Authority Agent CCITT The International Telephone and Telegraph Consultative Committee, (now called ITU-T (q.v.)) CSF Cryptographic Support Facility Page 13 of 173

21 CV Control Value DSA Digital Signature Algorithm ECMA European Computer Manufacturers Association. ISO International Standards Organization ITU-T International Telegraphic Union - Telecommunications (previously CCITT, (q.v.)). KDS Key Distribution Server. LRA Local Registration Authority OSI Open Systems Interconnection PAC Privilege Attribute Certificate PAS Privilege Attribute Server PKM Public Key Management PPID Primary Principal Identifier PV Protection Value PVF PAC Validation Facility RACF Resource Access Control Facility RSA The Rivest-Shamir-Adleman (asymmetric) cryptographic algorithm SACM Secure Association Context Manager SMIB Security Management Information Base SSO Single Sign-on SSSO Secure Single Sign-on TM Trusted Third Party The next chapter discusses the generic Single Sign-on concepts and expands on additional concepts for Secure Single Sign-on. Page 14 of 173

22 Chapter 2 2. SSO Concepts 2.1 Introduction The main goal of SSO is to eliminate the need for manually signing-on to different systems by providing a single, automated process for identifying and authenticating users. In it's simplest form, Single Sign-on (SSO) consists of a single userid and password to gain access to all enterprise computing facilities. Single Sign-On (SSO) is the concept of minimizing the number of different userids and passwords required to access various host systems in a distributed computing environment. In its purest form, single sign-on allows a user to sign -on once to the enterprise computing environment and be granted access to participating host systems across the enterprise.(deloitte & Touche,1996) Users who once entered different userids and passwords to access each information system environment, like a file server, UNIX host, mainframe host or application system, need only remember a single userid and password to access the participating hosts. Single sign-on can decrease the level of account administration required for an enterprise and reduce the likelihood that users will write down their userids and passwords. (Deloitte & Touche,1996) Single Sign-on (SSO) versus Secure Single Sign-on (SSSO). Single Sign-on (SSO) is a concept that provides the user with a single userid and password for access to all the resources on the enterprise network. The problem is, that in many cases, passwords and data are sent in the clear over the network, making it susceptible to interception and abuse. The concept of Single Sign-on can thus be extended to Secure Single Sign-on (SSSO) by also ensuring aspects of confidentiality and integrity. The following definition for Secure Single Sign-on can thus be formulated: Secure Single Sign-On is the ability to provide principals, after being authenticated once, with transparent access to a variety of services through a defined set of credentials from trustworthy certification authorities, via authorized applications, while maintaining end-to-end confidentiality, integrity and audibility.( Adapted from Stanley, 1996) Page 15 of 173

23 SSSO, to be implemented successfully, requires a carefully architected security design, consistent security policy enforcement and a single view of security management and auditing. The challenge is to apply these requirements to heterogeneous and distributed computing environments. When an organization is faced with the dilemma of selecting or building a solution for its SSSO requirements, there are very few, if any, standards to assist in making the right choice. Off -the -shelf products are generally immature and seldom cater for all circumstances. It is, therefore, essential to be able to measure products and in-house solutions against a common standard. Chapter 7 provides a framework for evaluating SSO and SSSO solutions. 2.2 Types of SSO Solutions There are several software products on the market that facilitate the implementation of single sign-on strategies. Available solutions fall into the following five main types: Synchronization; Scripting; Proxies and Trusted Hosts; Trusted Authentication Server solutions; and Hybrid solutions. Each of these are now discussed in more detail Synchronization solutions. These set a user's sign-on data (userid and password) to a consistent value on all target systems which he or she is entitled to access General Description Synchronization involves creating a single userid and password combination for each user, such that a user only has to remember one set of sign-on data to gain access to all systems he or she is permitted to use. However, users are still required to sign on to each system individually. The two types of synchronization solutions, namely manual synchronization and automated synchronization are discussed below: Page 16 of 173

24 ,Single Sign-on in Heterogeneous Computer Environments Manual Synchronization A crude, manual form of synchronization can be, and often is, implemented unilaterally by users. Users simply set their userids and passwords to the same value manually on all the systems they access. When required to change a password on one system, they change their passwords on all other systems they use, to accord with the new one. This solution is only an option when the systems accessed by a user have similar conventions for the format and content of sign-on data. It is not a serious proposition for organizations wishing to enhance corporate security Automated Synchronization A more efficient form of synchronization can be achieved by automating the synchronization process. Typically, automated synchronization solutions keep track of users and their passwords, enforce password rules ( e.g. for password formats, complexity, re-use and change) and ensure changes to each user's passwords are registered on all systems which the user is authorized to access. Synchronization is achieved by intercepting requests for password changes issued by target systems. Intercepted requests are conveyed to users. Users select new passwords. The synchronization solution then distributes these passwords to all systems which the users in question are authorized to access. (Stanley, 1996) Implementing Synchronization Synchronization software can be installed on a multi -purpose computer or on a dedicated platform. There are successful solutions based on commercially- available products. Others have been successfully developed in-house (Stanley,1996) Introducing automated synchronization entails establishing uniform conventions for userids and passwords across target platforms and applications. This provides the opportunity to apply consistent standards across multiple systems. It may also mean that the lowest common denominator has to be adopted, lowering the overall level of security Key Strengths of Synchronization The main strengths of synchronization are: saves users having to remember multiple sets of sign-on data provides an opportunity to enforce consistent standards for sign-on data and good sign-on practice across target platforms and applications Page 17 of 173

25 technique is mature solutions can cover a range of target systems, at modest cost (Stanley,1996) Key Weaknesses of Synchronization The main weaknesses of synchronization are: users still have to sign-on manually to each system if compromised, sign-on data provides unauthorized access to multiple systems sign-on data is liable to be compromised by target systems with weak access controls and transmission in clear synchronization is suitable only for target systems which have a common notion of how sign-on data is interpreted. Cross-system standards may be determined by the lowest common denominator synchronization products tend to support only a single type of platform, or narrowly -defined range.(stanley,1996) Scripting solutions. Another technique for implementing single sign-on is scripting, by which the commands that a user would normally enter manually, is recorded and replayed to automate the logon. This does not require changes to a user's existing sign-on data General Description A script is a string of commands and values that would normally be entered into the system. The script organizes these commands and values into a single module. So instead of executing each command individually, the script is executed by the SSO server to provide the user with the requested access. (Deloitte & Touche, 1996) Scripts may be stored on a removable medium (e.g. a smart card), users workstations or on a script server. (Stanley,1996) Implementing Scripting solutions Scripting solutions can be implemented based on commercially available products or successfully developed in-house. Deciding where scripts are stored is an important design consideration. Storing scripts on workstations avoids the cost of extra hardware(e.g. card readers, servers) but ties Page 18 of 173

26 users to particular workstations and leaves scripts vulnerable to unauthorized disclosure, unless stored encrypted. Storing them on smart cards is more secure and - as long as card readers are installed on all the workstations they use - benefits those who need to access systems from workstations in different places. Storing scripts on a server reduces the burden of distributing scripts to users or workstations and makes it easier to apply a consistent level of protection to stored scripts. Distributing scripts to individual workstations or users can be an administrative nightmare when large populations of users or workstations are involved. Since scripting solutions emulate user actions, they require no modification of target platforms or application systems. They can therefore support environments featuring diverse systems, including legacy systems where support may be limited or nonexistent. However, even minor changes to the sign-on process of target systems may require scripts to be updated Key Strengths of Scripting The key strengths of scripting are: saves users having to remember multiple sets of sign-on data saves users having to remember how to sign-on to different systems automated sign-on is more efficient than signing-on manually no changes are required to target platforms or application systems technique is well proven and a wide range of scripting products are available (Stanley, 1996) Key Weaknesses of Scripting The key weaknesses of scripting are: distributing scripts to individual users or workstations can become an unmanageable burden in large-scale implementations minor changes to the sign-on processes of target systems can cause scripts to fail, thus inconveniencing users if compromised, scripts enable unauthorized access to multiple systems special measures are needed to protect scripts stored on workstations and a consistent level of protection may be difficult to achieve scripts may be exposed to unauthorized interception by transmission in clear Page 19 of 173

27 the development of scripts demands detailed knowledge of target system, and considerable precision. (Stanley, 1996) a Proxies and Trusted Hosts. Another technique, using Proxies and Trusted Hosts, does not require any additional software General Description By setting up trust-relationships between hosts, and using proxy mechanisms, trusted users are logged on to any host in the trust-relationship without having to enter a userid or password. (Gregory, 1994) VMS uses Proxies to enable trusted DECNET access, while UNIX uses Trusted Hosts (.rhost tile) for trusted TCP/IP access. The basic mechanism is the same in both cases: A specified user on a specified remote system is registered as being a trustworthy user who need not use a password to access the tiles of a specified account on the node where the proxy/trusted host feature is enabled. It is assumed that the account of the user on the node is secure Key Strengths of Proxies and Trusted Hosts The following are key strengths of proxies and trusted hosts: saves users having to remember multiple sets of sign-on data saves users having to remember how to sign-on to different systems automated sign-on is more efficient than signing-on manually no changes are required to target platforms or application systems users only have to sign-on once to their workstations using a single userid and password no additional software is needed- it is a standard feature of VMS and UNIX it is easy and quick to implement Key Weaknesses of Proxies and Trusted Hosts The key weaknesses of proxies and trusted hosts are: the security of this solution is based entirely on the strength of initial authentication and then trusting the workstation if the workstation is not 'live' on the net, it could be masqueraded by another there is no re-authentication before any resources on remote servers are accessed - thus no audit trial or proof of identity exists once the security is compromised, the entire domain of trusted servers is compromised Page 20 of 173

28 it cannot be used for privileged accounts because of the above vulnerabilities (Gregory, 1994) Trusted Authentication Server solutions. Trusted authentication servers are an emerging type of solution. The technique was pioneered in the 1980's by the Massachusetts Institute of Technology (MIT), working with IBM and Digital Equipment Corporation. These provide a more secure, encryptionbased authentication General Description With trusted authentication servers, a common database is built containing a list of users and cross-references to valid host systems, userids and passwords. When a user accesses the network, they sign -on through the trusted authentication server and are granted access to the host systems. This type of solution normally requires applications and systems to be specially adapted to enabled the security features to be utilized, i.e. implementation of DCE, or Kerberos. (Deloitte & Touche,1996) In day- to-day operation, a user signs-on to the trusted authentication server, which verifies his/her identity and issues the user with a 'credentiala credential is a string of data, containing encryption keys which target systems can use as evidence that a user is who he or she professes to be. The user can then gain access to target systems simply by presenting the credential. Once issued, a credential can be stored by the user for re-use(e.g. until he or she terminates the session). As far as the user is concerned, he or she has only one set of sign-on data to remember, and only one sign-on process to go through. A feature of the trusted authentication server approach is that there can be mutual authentication between user and target systems, since the encryption- based authentication process can also be used not only to confirm that users are who the say they are, but also to verify the identity of target systems. This combats 'spoofing' attacks. Encryption can also be used to provide other services (e.g. message integrity, message confidentiality) which are essential for achieving Secured Single Sign-on. Page 21 of 173

29 Implementation of Trusted Authentication Server Solutions Trusted Authentication Server Solutions can be implemented based on commerciallyavailable products. Developing a solution in-house will generally not be a realistic option. Solutions have four main components: the trusted authentication server itself, which maintains a database of target systems and authorized users software installed on user's workstations, which communicates with the trusted authentication server, stores credentials and presents them to target systems software installed on target platforms, which receives and interprets the credentials presented by user or other systems an Application Programming Interface (API), used to pass authenticated user identities to target application systems. Implementing these components involves installing the server, setting up its database, installing software on all user's workstations and on target platforms and modifying target applications in accordance with the API. Trusted authentication servers offer the most secure means of achieving single signon, although they are not entirely immune to attack by determined knowledgeable individuals. (Stanley, 1996) Key Strengths of Trusted Authentication Servers The main strengths of Trusted Authentication Servers are: saves users having to remember multiple sets of sign-on data saves users having to remember how to sign-on to different systems automated sign-on is more efficient than signing-on manually the burden of managing sign-on data is removed from system administrators of target systems user administration can be managed at a single point to a consistently high standard strong authentication is provided, and mutual authentication between users and systems no authentication data is transmitted in clear the approach is in line with the strategic direction of much of the computer industry and solutions are available on an increasing number of platforms. Page 22 of 173

30 Single Sign-on In Heterogeneous Computer Environments Key Weaknesses of Trusted Authentication Servers The weaknesses of trusted authentication servers are: implementation costs may be high because of the need to modify target applications to conform to the API it may be difficult to modify legacy systems to conform to the API software products must be installed on target platforms, and may not be available for all of them restrictions on the use of particular encryption technologies may limit the security of solutions or their availability. (Stanley, 1996) Hybrid solutions. These combine a trusted authentication server solution with one or more of the other types to allow single sign-on to be achieved across both specially adapted and unadapted systems. This allows new systems to utilize the benefits of trusted authentication, while using scripting for legacy applications. (Stanley, 1996) General Description In operation, users sign-on to the hybrid server. The server completes the sign-on process automatically, via a credential or a script depending on the target system being accessed. Hybrid solutions allow the most appropriate sign-on method to be applied to individual platforms and applications. Trusted authentication server approach can be used where practicable. Scripting provides a fall-back solution for target platforms and applications ( e.g. legacy systems not otherwise easily accommodated) Implementation of Hybrid Solutions Implementation entails: determining which method is most appropriate for providing access to particular target systems installing software products to support the trusted authentication server approach on selected workstations and target platforms, and modifying the selected target applications to conform to the API Page 23 of 173

31 developing scripts for platforms and applications systems not covered by the trusted authentication server approach installing the hybrid server and setting up its database of authentication data and scripts Hybrid solutions provide all the features desirable in a single sign-on solution. As a result, they can contribute to improving user satisfaction and efficiency, cutting the cost of system administration and reducing the risk of unauthorized access to target systems and data Key Strengths of Hybrid Solutions In addition to the combined strengths of Trusted Authentication Server Solutions and Scripting Solutions, the main strength of the Hybrid approach is that it can provide single sign-on across the entire spectrum of target platforms and applications Key Weaknesses of Hybrid Solutions The weaknesses of Hybrid Solutions are simply the combined list of weaknesses of Trusted Authentication Server Solutions and Scripting Solutions. (Stanley, 1996) Conclusion Of the above, only Trusted Authentication Server solutions fit squarely into the SSSO concept. Hybrid solutions contain all of the SSSO functionality, but the extension of functionality with other methods like scripting, may actually reduce the level of security to some applications and systems. 2.3 Security Services Required for SSSO In order to implement SSSO, as previously defined, the total or partial integration of the following security services into the solution is essential: Authentication, Authorization/LogiCal Access Control, Security Management and Administration, Auditing, Cryptographic services, Key management, Integrity, Confidentiality and Availability. The required components of a comprehensive SSSO solution as defined by Pfleeger (1989), are briefly discussed below: Page 24 of 173

32 _Single Sign-on in Heterogeneous Computer Environments Authentication and Single Login (Sign-on) 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. This requirement is essential to confirm the identity of a communicating party, ensuring that only authorized people are allowed access. It is also essential that authentication happens on an individual level, i.e. any action can be uniquely linked to a specific subject or object, enforcing total accountability. 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 modules of the different servers accessed across potentially insecure communication links. Cryptographic mechanisms can be used to help in this task. Authentication can be done in several ways, the simplest is by supplying an identity and password, extending to more sophisticated techniques like secure tokens containing the users password, public /private key technology (strong authentication), or even some biometric information about the user Authorization and Logical Access Control. Authorization is enforced by logical access control. Logical access control ensures that only authorized users (subjects) get access to those resources (objects) they are authorized to access. Logical Access Control also controls the rights users can have to resources - for e.g. read, write, execute, delete rights etc. Different levels of granularity in terms of resources can be implemented. This can be done via an Access Control List (ACL) centrally, or locally, based on groups or role profiles. When there is only one central computer in a system, all of the Access Control Information relating to the user can be held by that computers operating system - everything is in the same place. The user signs on, and the resulting Page 25 of 173

33 authenticated identity is used in the central computer to obtain the Privilege Attributes that apply to that user. In distributed systems supporting single sign-on, it is possible to store the Privilege Attributes away from the target end-system in a separate secure source 'Pull' versus 'Push' There are two ways in which Privilege Attributes can be obtained. They can either be "pushed' to the target by the accessing initiator, after first obtaining the access information (certificate) it needs from the secure source, 'or "pulled' by the target (the initiator simply provides its authenticated identity, and the target uses this to get the Privilege Attributes from the secure source). The push model has several advantages: in terms of performance: access decisions can be taken immediately by the target without extra communication, in terms of communication cost the access to the place where the Privilege Attributes are held will in general be made less often by the initiator than the alternative of once for every target accessed, in terms of tempered Privilege Attributes: architecturally the choice of Privilege Attributes may depend 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 Privilege Attributes needed for making its access control decisions, no more. (Parker,1995) Integrity. Data Integrity means that assets can be modified only by authorized parties. This is implemented using Message Authentication Codes (MAC's), to prevent it from being undetectably tampered with Confidentiality. Confidentiality or secrecy means that the assets of a computing system are accessible only by authorized parties. This is usually implemented through encryption. Page 26 of 173

34 2.3.5 Availability. Availability means that assets are available to authorized parties. An authorized party should not be prevented from accessing those objects to which he or she or it has legitimate access Non- repudiation. This means proof that a message received was not fabricated by someone other than the declared sender. This is implemented using digital signatures Security Management. Effective management is the basis of any Information Security system. management facilities are needed. These include: Full Administration. User friendly administrative tools to administer logical access control through profiles Auditing. For effective management of Information Security, full and proper auditing facilities should be available on all levels of the Environment. These auditing facilities include the logging of all relevant (selected) actions, and the proper tools to investigate the audit logs. On-line exception reporting should be possible. _ Cryptographic Services and Key Management. To implement Confidentiality and Non-repudiation and Strong Authentication, cryptographic services are needed. For Confidentiality the most common symmetrical algorithm used is DES (Data Encryption Standard) To implement non-repudiation and strong authentication, asymmetrical algorithms like RSA are needed. 2.4 Additional SSSO Concepts Security over an Insecure Network SSSO solutions generally assume 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. This is especially appropriate where enterprise networks make increasingly use of open standards (e.g. TCP/IP) and can no longer rely on technologies like SNA and LU6.2 to provide integrity and confidentiality services. Page 27 of 173

35 The approach generally has been to minimize the use of encipherment by ensuring that it is used only in the most appropriate places, such as the protection of keys. Wherever possible, security control data exchanged is protected against modification by tamperproof sealing rather than encipherment (the exception to this is when standard enciphered tokens conforming to Kerberos are used). In addition however, any user data may be optionally confidentially protected when requested by either the initiator or the target 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 (usually Directory Certificates), signed by off-line trusted authorities, can be used to verify the integrity and authenticity 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 Privilege Attributes can be performed directly by each target without having to have online 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 certificate 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 can not be memorized by human principals, so they must either be given a portable device containing their private key, such as a smart card, or their Page 28 of 173

36 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, all components of a system implementing the architecture need to be able to support public key cryptographic operations. (Parker, 1995) There is thus a clear advantage of having an on-line security server which is constantly aware of all users logged-on and can instantaneously alter the Privilege Attributes of any principal Heterogeneity of Privilege Attributes 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 sets of Privilege Attributes for each of these end-system types simply because they handle the same global values in different ways. For example, if a user's access rights to these applications are based on 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 Privilege Attribute Service, once as a UNIX group and once as each of the proprietary forms of group. The European Computer Manufactures Association (ECMA) (Parker,1995) work attacked this problem by defining standard Privilege Attribute types that are independent of specific end-system representations but can be mapped into them as appropriate in the receiving system. This leads to better interworking potential as well as easier management of Privilege Attributes. Facilities are provided in the target system for an application to extract this value exactly as it was received, enabling it to use it directly in access control decisions. This has 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 values, not local values. Page 29 of 173

37 2.4.4 Uses of Identity Identity is a real world attribute that has multiple uses in a computer system. Indepehdently of what types of identity attribute may exist, or what they are called, some of the uses to which identity may be put, are: as a means of claiming the identity of the principal when logging on to a system to help the system locate the authentication information that it will use for verification. Call this use "Login" or "Sign-or!'. as a means of making the principal accountable for his 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 "Accessn. as a means of identifying the principal as the originator of a piece of data so that the receiver can prove origination to a third party. Call this "Non-repudiation". as a means of locating and permitting the release of your Privilege Attributes within a Privilege Attribute Service. This is a special case of the "Access" use. Call this use "Access to Privilege Attributes". All of these uses could in theory be encompassed by implementing one single type of attribute called "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. (Parker,1995) Roles It is important that a SSO solution supports real world access control policies that are based on the concept of a user's organizational 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. Page 30 of 173

38 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, and the controls which are to apply to their use. 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 does not need to be aware of the Privilege Attributes he has. The most he needs to know are his different role names (e.g. quality controller, or pay clerk) and select one of these. However he does not necessarily even need to know these since he always has either an individual default role name or the system default role name, 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 Access Paths and Delegation 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 Privilege Attributes, effectively impersonating the original initiator (at least to the extent that the Privilege Attributes themselves permit).this is the simplest form of delegation. In other cases a full trace Page 31 of 173

39 of the route by which the action was performed may be needed, particularly if the initiator's Privilege Attributes are not sufficient by themselves to authorize 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, PACs can be arranged to be valid only for specific nominated targets. A PAC may contain more than one target name. In some situations delegation is not appropriate and mechanisms should be provided to prevent a PAC from being delegated Security policies and security domains As defined in ISO , a security domain is a set of elements, a security authority and a set of security relevant activities in which the set of elements are subject to the security policy, administered by the security authority, for the specified activities. A security policy may be interpreted at the engineering level as a set of security rules. Overall authority can be devolved within a security domain into separate more specialized authorities, to provide separation of duty. (Parker,1995) For an initiator to be a member of a security domain it needs to have a name and initiator authentication information associated with it, registered in the Authentication Service of the domain. Humans obtain initiator authentication information, such as a login identity, a password, or a private key from a human authority. Application initiators have equivalents of both the name and the authentication information, the password being a true cryptographic key Trusted Third Party (TTP) Components On-line authorities There are four trusted on-line authorities and one on-line untrusted service (Parker, 1996). The authorities are: the Authentication Authority, the Privilege Attribute Service Authority, the Key Distribution Authority, and the Local Registration Authority (LRA). The on-line untrusted service is the Certification Authority Agent (CAA). Their respective roles are as follows: the Authentication Authority authenticates principals acting as initiators, the Privilege Attribute Service Authority certifies access privileges Page 32 of 173

40 of principals acting as initiators, the Key Distribution Authority provides keys to principals, acting either as initiators or targets, to protect the exchange of security information (i.e. PACs and related control information). From these keys, others may be derived for use in securing the operational exchanges authorized by PACs. The LRA is the authority from which entities may request the generation of asymmetric key pairs. The CAA receives and responds to such requests when forwarded from (and therefore authorized by) Local Registration Authorities. The CAA communicates with the (off-line) CA. The CAA acts as a request collector and spooler. It cannot manipulate requests in any way because they are signed by the requesting LRA. Each authority (and the CAA) is implemented as a server, and this leads to the recognition of the following components: the AS, the PAS, the KDS, the LRA and the CAA Off-line authorities 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). ACA is responsible for the production of Directory Certificates containing public keys so that anybody who trusts the CA can check a signature produced by an entity whose public key is known. The CA has no further responsibilities; it operates off-line since the Directory Certificates contain all the information needed by its clients. It interfaces with the outside world using file transfer. The CA exchanges such files with the CAA. A principal acting as an initiator is permitted to have authentication information by an Authentication Authority, which authorizes the installation of corresponding verification information in the principal's Authentication Server. In the case of a private key used in authentication, the Authentication Authority may obtain the key pair via the LRA. A security domain supporting both principals acting as initiators or as targets makes use of all the servers previously identified. A security domain which only supports target applications would not need the AS and PAS components. It would even not use a KDS if target application PVFs are given (public) keys by a CA. Page 33 of 173

41 For the generation of asymmetric key pairs, an LRA needs to be present. This will typically be in the same domain as the key pair requester, though it need not be. Also, a CM associated with a CA must be established. A CAA or CA need not be in the same domain as the LRA; indeed, they may serve several security domains Initiator Components There are three main Initiator components: the User Sponsor (only present when the principal is a human entity) which is the interface of the user with the system, the APA Client which is the interface with the AS and PAS, and the initiator end of the distributed Secure Association Context Management (SACM) component, which is the interface with the PAS and the target end-system Target Components There are two main target components: the target end of SACM which is the interface between the target application and the initiator machine, and the PAC Validation Facility (PVF) which is a trusted piece of code used by the target SACM to validate the PAC, get the PAC contents and get the keys to secure the subsequent conversation with the initiator Trust Model Each human user principal is given a login name so that it can authenticate to an AS. It is also given an authenticated identity which can then be recognized by a PAS. It can then obtain from a KDS the keying information to be used to secure exchanges with target end-systems. Hence there are two links in a chain of trust: one to get a PAC and one to get the keying information. The first link is where the PAS trusts the AS to authenticate the principal correctly. The second link is where the KDS trusts the PAS to provide the proper protection for performing the key request. From a target perspective, a target application is "sponsored" by a PVF. Each target application is given a name and is associated with a PVF. Each PVF knows the name of the applications it supports. A PVF is either sponsored by a KDS or by a CA (the first case applies to the use of a shared secret key between the PVF and the KDS that the PVF trusts, while the latter applies for the use of a public key for the PVF). The association between the name of the PVF and the name of the target application is Page 34 of 173

42 established and maintained by the guarantor of the PVF. Thus two cases need to be considered: when the guarantor is the domain KDS, the association is recorded in the KDS, thus each KDS knows the different applications supported by every PVF of its domain, when the guarantor is a CA, the association is recorded in the Directory Certificate of the PVF, which associates the name of the PVF with the name of all the target applications it supports. the asymmetric algorithm and public key value used by that CA, the validity time period of that public key. Each PVF also identifies the names of the PAS's that it globally trusts. Thus, it is not possible to specify that for one of the PVF's applications a certain PAS is trusted, but for another a different PAS. A target application trusts its PVF. The administrator of a PVF is thus able to enforce the security of a target application provided that he has been-allowed either to register the PVF with a target KDS or to obtain a Directory Certificate from a CA trusted either by an initiator or by the initiator's KDS. The authority of the KDS or the CA administrator over that PVF's applications is thus partly delegated to the PVF administrator. The content of the PAC and PAC controls are released by the PVF only if the authority that issued the PAC is trusted by the PVF. Access may be granted if both the PAC and the keying information are acceptable to the PVF. The PAC can be trusted if it comes from a trusted authority and if the Directory Certificate corresponding to the private key used to sign the PAC is valid. The keying information has different forms, depending on whether the access is intradomain or interdomain, and on what cryptographic technology is being employed. For the intra-domain case (i.e. if it has been issued by the KDS of the PVF's domain), or when key distribution is done using only asymmetric keys, the keying information is directly computable by the PVF. Page 35 of 173

43 For symmetric or hybrid key distribution in the interdomain case, symmetric keying information will need to be processed by the KDS of the PVF. In this case, there is an extra link added to the trust chain: the PVF trusts its KDS which in turn must trust the KDS of the initiating domain. For this purpose, the target KIDS maintains a list of KDS's it trusts when processing the keying information from other domains (i.e. a "trusted list"). In the same way, the initiator KDS maintains a list of KDS's it trusts when providing the keying information for other domains (i.e. a "trusting list"). 2.5 Cryptography and Key Management Cryptography and Key Management were identified as basic requirements for Secure Single Sign-on in 2.3 above. It is now discussed in more detail: 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 Algorithms Three kinds of cryptographic algorithm can typically be used: 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. This type of algorithm is used in particular to protect communication exchanges, either for integrity protection or confidentiality protection, asymmetric algorithms (sometimes called public key 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. There are two forms of asymmetric algorithm: reversible (e.g. RSA) and non-reversible (e.g. DSA). Page 36 of 173

44 _Single Sign-on in Heterogeneous Computer Environments one-way algorithms, where it is possible to encrypt the data but where reconstructing the original data from the encrypted data is computationally intractable. This type of algorithm may or may not involve the use of a secret key Basic Keys and Dialogue Keys The exchanges between the initiator and target are secured using a two level key scheme in which a distinction is made between basic keys and dialogue keys. A basic key is a temporary key established between an initiating machine and the PVF of the target application. The basic key is used for integrity protecting the PAC, associated PAC control information, its own key establishment information in transmission and the information used to establish dialogue keys. In the target endsystem only the PVF ever learns the basic key. The basic key is established by means of the initiator sending keying information to the target in a construct called a basic key package which can take different forms depending on whether the initiator and target are in the same security domain or not. 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 keys that the initiator SACM is expecting to be used 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 subsequently not to use dialogue keys at all for user data exchanges, 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 Key Management The process of installing cryptographic keys and managing their use is called Key Management. One aspect of this is Key Distribution. In most real systems it is not Page 37 of 173

45 practical to store at each principal all of the keys of the other principals it may wish to communicate with. There are two approaches to solve this problem: The first approach is to subcontract the construction of working keys to a Key Distribution Service, which knows the long term keys of the other principals in its domain, The second is to provide long term private keys so that principals knowing the corresponding Directory Certificates can themselves build the working keys 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. 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 license. 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. When encipherment of user and system data is a local security policy requirement, the SSSO solution should allow the algorithms and keys used to be separately specified, permitting them to have characteristics acceptable to the prevailing political environment. 2.6 New vulnerabilities introduced by SSSO While single sign-on reduces the likelihood of users compromising their passwords, it can also introduce new vulnerabilities. These are: Single-point-of-failure: Some single-sign on solutions rely on dedicated authentication servers to support users. Multiple users may be inconvenienced if a server goes down. This can be addressed by introducing back-up (fail-over) servers, as well as alternate access paths to these servers. (Deloitte & Touche; 1996) Multiplied access: The risk of unauthorized access may be increased rather than reduced where single sign-on solutions are introduced, which if a user's password is disclosed, permit Page 38 of 173

46 Single Sign-on In Heterogeneous Computer Environments unauthorized access to all systems accessible to the user. The use of secure physical tokens for authentication can mitigate this vulnerability Insecure storage: Sign-on data enabling access to multiple systems is exposed to unauthorized disclosure if stored insecurely by target systems, workstations or servers. Critical signon data should be stored in encrypted format where possible. Cryptographic keys should be stored in tamper resistant security modules (TRSMs) Insecure transmission: Sign-on data is exposed to unauthorized interception if transmitted in clear, particularly when transmission is across networks using broadcast protocols ( e.g. Ethernet or Token ring) which expose sign-on data to interception at all network nodes. The risk increases in line with the number of nodes and when networks extend outside the company. Sign-on data should be encrypted when transmitted over networks. (Stanley, 1996) 2.7 Obstacles and Pitfalls to be considered Although single sign-on has long been recognized as desirable, but few organizations have so far managed to introduce practical secure single sign-on solutions across multiple platforms and application systems. SSSO requires a detailed plan for effective implementation. Without a proper design, a SSSO system can create pitfalls for users and administrators. There are several obstacles and pitfalls to be considered: Immaturity of Products. The latest generation SSSO products are generally immature. No product as yet offers a perfect solution and there are obvious dangers in installing fast-moving technology which may be subject to bugs or unforeseen limitations, or obsoleted by further advances Lack of experience. The limited number of successful SSSO implementations, plus lack of first-hand experience leaves information security managers, IS strategic planners and system developers uncertain about when and how to introduce single sign-on, and which solutions to specify. Uncertainties are compounded because the capabilities of single sign-on products, and the ease with which they can be introduced, are frequently oversold. Page 39 of 173

47 2.7.3 Uncertainty about Costs and Benefits. The relative immaturity of the field as a whole and the pace of change mean that there is widespread uncertainty about the costs and benefits of single sign-on. Costs are difficult to assess without detailed study. They vary depending on the nature of the single sign-on solution selected, method of implementation, number of users and the number and diversity of target platforms and applications, and can be substantial for implementations supporting many users. (Stanley,1996) Scalability. Scalability of the solution seems to be another major concern, both in capability of handling peak demands, such as concurrent sign-on's in the mornings and manageability across the enterprise Dependence on Architecture. SSSO solutions are dependent on the enterprise systems architecture, e.g. dumb terminal - host, client- server, two- or three-tier architectures, etc. Therefore, not every SSSO solution would be compatible with a given enterprise architecture Catering for future requirements. There are few, if any, software solutions that accommodate all of the top operating system environments. So tailoring the right mix of solutions to the enterprise's information technology architecture and strategic direction is essential. Achieving technical integration across multiple platforms and applications is a major challenge, particularly when target systems and applications are themselves subject to constant change. Not all SSSO solutions are capable of meeting this challenge. Some entail significant change to platforms, applications and overall system architectures Conformance to Standards Some products may offer the full functionality required, but by propriety technology. Unless the solution conforms to internationally accepted standards (e.g. OSI, ECMA, ISO, OSF), adaptability and flexibility may be sacrificed. Upgrades or changes to the enterprise environment will become a major headache. It is therefore advisable to stick to standards wherever possible Cost of features not required. Most SSSO software packages include more features than just SSO, thus the price paid for SSO includes other capabilities, which may be redundant with existing controls and management tools. Page 40 of 173

48 2.7.9 Establishing Single Userids. Establishing single userids in an enterprise is not a trivial management and administrative task. It is essential that implementation can be done in a phased manner. (Deloitte & Touche, 1996) Security Management and Administration The logistics of security management, administration and audit are often ignored or brushed aside. It is essential that due thought be given to all these logistical issues and that these requirements form part of initial evaluation of any potential solution. (CKS,1996) Security Certification It is the author's opinion that the SSO product should be certified in terms of acknowledged international security standards, i.e. ITSEC E2 Level, C2 level of the US Orange Book. Certification has obvious advantages, both to the manufacturer and prospective buyer of a SSO solution. The client can then be assured of the level of security achievable with the product, if correctly installed and configured. It should be a relatively simple exercise to verify the actual installation to the prescribed standards to which the product was certified. 2.8 Conclusion There are five types of SSO solutions which may be suitable for various reasons, especially compatibility with legacy applications. The extension of the concept of Single Sign-on to Secure Single Sign-on, leads to added requirements in terms of security services like authentication, authorization, integrity, confidentiality, non-repudiation, management and administration and cryptographic services. SSSO solutions can actually provide comprehensive and integrated enterprise security products. Of the five types of SSO solutions discussed in this chapter, the Trusted Authentication Server and Hybrid solutions provide the most consistent and comprehensive security solutions. It is also consistent with, and generally makes use of technologies like Kerberos, DCE, SESAME and GSS-API, which are discussed in Chapter 3. Single Sign-on is only one of the security functions offered. The added vulnerability of multiplied access should be addressed by using a secure token like a smart card, which cannot be duplicated. This would have the added benefit of securely storing cryptographic keys needed to implement some of the other security services like confidentiality and non-repudiation. Page 41 of 173

49 Chapter 3 3. Enabling Technologies for SSO and SSSO 3.1 Introduction This chapter is dedicated to so-called enabling technologies for Single Sign-on, as well as for Secure Single Sign-on, which have become standards in their own right, either by widespread use, or by being "open'. The latter means that algorithms and APIs are exposed for general use by other products to enhance portability, functionality and interoperabi I ity. 3.2 OSF DCE Open Software Foundation (OSF) Distributed Computing Environment (DCE) is one of the two open standards for distributed processing which are having a major influence on the development of single sign-on solutions. The other is SESAME, which is discussed in chapter 5. In many way these can be seen as linked, rather than competitive developments, since there is considerable cooperation between the parties concerned. (Stanley,1996) Standard for Secure Distributed Processing DCE consists of specifications and software. It has been termed 'middleware' or 'enabling technology'. It is not intended to exist alone and is not an application in itself. Rather, it is designed to be integrated with a vendor's operating system and used to build custom applications or to support software products, meaning products which incorporate DCE and conform to DCE specifications. It is the most widely supported standard for secure distributed processing. The majority of computer vendors are providing DCE-based products. Many have DCE solutions for other vendors' platforms. In addition, database manufacturers, including Oracle, have stated their intention to move towards DCE compliance DCE Security Service DCE consists of multiple components that have been integrated to work closely together. A key component is the Security Service. This uses the Kerberos authentication protocol (see 3.4), with enhancements included to provide scalability and a wider range of services. Thus, a highly -influential development in secure single sign-on is at the heart of DCE. Page 42 of 173

50 The Security Service is a required component in any DCE implementation and is part of what is referred to as DCE's 'secure core'. DCE itself does not provide single sign-on. However, DCE has been used to create single sign-on solutions that interface with both legacy and newer systems that support DCE. DCE stems from work carried out under the aegis of the Open Software Foundation (OSF). OSF has now merged with X/Open and the combined organization remains heavily committed to DCE Public Key Support A new version of DCE (V1.1) has recently emerged. A forthcoming version (V1.2) will provide public-key based sign-on. It is being specifically designed to facilitate the use of smart cards containing users private keys. Alternatively, it will be possible to hold a user' private keys in encrypted form on a server. Future releases are expected to enable the use of public keys to support single sign-on without a central authentication server. (Stanley,1996) DCE is discussed in more detail in Chapter SESAME Secure European System for Applications in a Multi-vendor Environment (SESAME) is an architecture that implements a model for the provision of security services within open systems developed by the European Computer Manufacturers Association (ECMA). The architecture was developed and implemented on a trial basis, by Bull, ICL and Siemens- Nixdorf in an initiative supported by the European Commission.(Parker,1996) SESAME Objective for SSO The primary objective of SESAME is to support secure single sign-on and distributed access control. A key feature is its ability to inter-operate with legacy applications, thus easing the transition to systems which employ the full SESAME protocol. Interfacing with existing applications and systems is enabled by the SESAME credential or privilege attribute certificate (PAC). A PAC can securely transfer a variety of sign-on data, including the userids and passwords to a particular system.(stanley,1996) Another requirement addressed by SESAME is the need to be able to audit users' actions across multiple, distributed systems. In this case SESAME supports the use of an 'audit identity' which is securely passed inside PAC's. Page 43 of 173

51 Single Sign-on in Heterogeneous Computer Environments Use of Public-key Cryptography The SESAME architecture recognizes the need for a scaleable, long-term, multi-vendor solution. It is based upon the technology of public-key cryptography. This is potentially more powerful than the traditional secret-key cryptography of, for example, Kerberos, and should require less of an administrative burden. However, the task of upgrading the majority of systems to support this is difficult. Because of this, the developers have offered alternatives which, in the short term, allow compatibility with systems such as Kerberos and DCE. While SESAME is in itself not a product, its three developers (Bull, ICL and Siemens Nixdorf) are producing single sign-on products which are based on it. Integration with DCE is a continuing goal of SESAME. (Stanley, 1996). Because SESAME is considered to be a prime contender as a solution for a comprehensive Secure Single Sign-on product, it is discussed in detail in Chapter Kerberos Kerberos was designed for distributed networks, and is a standard for remote authentication in networked client-server environments. Kerberos provides a means of verifying the identities of principals, (e.g., a workstation user or a network server) on an open (unprotected) network. This is accomplished without relying on authentication by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under assumption that packets travelling along the network can be read, modified, and inserted by will. (Kohl & Neuman, 1993) Kerberos is part of project Athena which was initiated at Massachusetts Institute of Technology (MIT). Kerberos is a trusted third party authentication service, based on the model presented by Needham and Schroeder, which employs a distributed client-server architecture. The Kerberos Authentication Server provides a properly authenticated user with a way to prove his identity to servers scattered across the network. (Steiner, 1988) Secure Authentication The MIT implementation confirmed the practicality of a secure authentication system operating over insecure networks. It allows entities communicating over networks to prove their identity to each other while preventing eavesdropping or replay of authentication data. It also provides for the integrity and confidentiality of the data transmitted using cryptographic systems such as DES. (Stanley,1996) Kerberos describes the protocols used by clients, servers, and the Kerberos servers to achieve authentication. It also describes the management and replication of the database which is required. Page 44 of 173

52 3.4.2 Kerberos Tickets Kerberos provides more than simply an authentication service. It is built around the concept of a Ticket Granting Server (TGS), to which access is controlled by the Kerberos Authentication Server (KAS). A ticket is a token issued to a client by the Kerberos server for presentation to a particular server, verifying that the sender has been recently authenticated by Kerberos. Tickets include the client's identity, an expiry time and a newly generated session key for use by the client and the server. It can define multiple secure areas, administrative domains, or realms, on a single enterprise network, without degrading the performance of the system, since tickets are reusable. The security of Kerberos relies on the security of several authentication servers, but not on the system from which users log in, nor on the security of the end servers that will be used. Authorization and accounting schemes can be built on top of the authentication that Kerberos provides, as these schemes are not provided within Kerberos. Kerberos utilizes trusted third party authentication, private key encryption (DES), and time limits Kerberos Security Exposures There are some criticisms of environmental shortcomings and security exposures within Kerberos. These existed primarily in Kerberos V4, but some are still valid for V5. For example, Kerberos uses untrusted workstations that are not reset between individual sessions, making it possible for an attacker to deploy Trojan horses and other malicious software attacks to gain access. Denial of service attacks are not solved with Kerberos V5. There are places where an intruder can prevent an application from participating in the proper authentication steps. Detection and solution of such attacks are left up to human administrators to resolve. Kohl & Neuman, 1993) Another point is related to the fact that the system was primarily designed for user-to-host authentication, and not for user-to-user or host-to-host authentication. This might create difficulties in environments in which hosts have identities of their own and need to access resources such as remotely mounted file systems on their own behalf. To do so within the Kerberos model would require that hosts maintain secret keys. If an intruder somehow steals the secret key, it can masquerade as the server. ( Kohl & Neuman, 1993) A related issue is the vulnerability of a ticket and session cache to illegitimate reading. Anyone who can read a cached session key can impersonate the legitimate user. The corresponding ticket can be picked up by eavesdropping on the network, or by obtaining privileged status on the host. Another problem is that if a user wants to submit a batch job Page 45 of 173

53 to be performed at a later time, he must be authenticated at the time or submit a password in the batch file. Furthermore, Kerberos is vulnerable to password guessing or dictionary attacks and also 'verifiable password ' attacks. The later means that, if an attacker can intercept the message from the AS to the client with an encrypted key derived from his password, a password guessing attack can be launched to discover the password. Note that both these vulnerabilities can be mitigated by well-chosen passwords. [Oppliger,1996] Despite the criticisms noted above, the Kerberos protocol is used widely within different single sign-on solutions, including DCE and SESAME. Kerberos Version 5 is now available in commercial products. All the above-mentioned security features can be obtained without any additional hardware costs. The following two sections discuss the Distributed System Security Arhitecture (DSSA) and The Exponential Security System (TESS). References to these technologies were exclusively gleaned from Rolf Oppliger's book on 'Authentication Systems for Secure Networks'. (Oppliger,1996) 15 Distributed System Security Architecture (DSSA or SPX) Background In the late 1980's, the Digital Equipment Corporation (DEC) proposed a distributed system security architecture (DSSA) which focused on the question of how to provide security services in a distributed environment. DSSA followed a hybrid approach in terms of cryptography: it uses secret key cryptography to provide data origin authentication, confidentiality and integrity services, and public key cryptography to provide entity authentication services. The DSSA's authentication service was named distributed authentication service (DASS). The service was prototyped in as authentication and key. distribution service named Sphinx. This was later renamed to SPX (still pronounced Sphinx). SPX uses DES as a secret key cryptosystem, and RSA as a public key cryptosystem. DES can be substituted for an alternate cryptosystem. (Oppliger,1996) SPX Development Stopped In spite of the fact that SPX has attracted much attention throughout the network security community, the development of the system was aborted after version 2.4 in DEC is now promoting Kerberos and OSF DCE products to meet the security requirements of its clients. Page 46 of 173

54 _Single Sign-on in Heterogeneous Computer Environments The SPX source code is freely available today and has been used in a proposed secure Telnet service in RFC 1412 in 1993, and more recently, a simplified version of DEC DASS was proposed as simple public-key GSS-API mechanisms (SPKM) in an Internet-Draft. (Oppliger,1996) 3.6 The Exponential Security System (TESS) The Exponential Security System (TESS) is a set of different, but cooperating cryptographic mechanisms and functions based on the primitive of discrete exponentiation. The system is being developed at the European Institute for System Security (EISS) of the University of Karlsruhe in Germany TESS Toolboxes TESS basically consists of five toolboxes which are implemented in the programming language C (ANSI-C) : A Long integer arithmetic toolbox that supports arithmetic with long integer operands up to a length of 4,096 bits. A cipher toolbox that consists of two modules, one handling stream ciphers based on linear feedback shift registers, and the other handling block ciphers. A chipcard toolbox that implements a three layer prot000l suite for communications with chipcards. The first layer consists of a system-dependent module handling serial communications between a host system and a chipcard reader over a serial line. The second layer is used to drive a chipcard reader over a serial interface, and the third layer implements the actual transport protocols. An authentication toolbox implements the KATHY protocols consisting of three classes of application functions, namely Functions for starting an authentication and for terminating an encrypted session; Status functions that provide an application with various information about the state and parameters of the authentication and the name of the communicating partner; Some filter functions that may be used by an application to process all incoming and outgoing data. A support toolbox that contains functions to support a broad range of hardware platforms and operating systems. Page 47 of 173

55 3.6.2 TESS Applications TESS has been used to build two application packages so far, namely the Secure Local Area Network Environment (SELANE) and the Exponential Electronic Signature (EES). (Oppliger,1996) 3.7 IBM Network Security Program (NetSp) IBM NetSP enables mutual authentication between two communicating principals and enables sign-on to multiple applications controlled by RACF without passing passwords in clear across the network. The RACF sign-on uses 'pass tickets' (discussed in the next section). Sign-on to Novell servers and to OS/2 LAN servers is achieved via scripting language that also does not transmit passwords in clear. Those applications which support the GSS-API are authenticated using the 'KryptoKnight' protocol, an implementation of the dedicated authentication server approach. (Stanley,1996) According to IBM (IBM SSSO Q&A, 1996) NetSp has been 'stabilized', which means that no future development or enhancements are being made to the product. "However, since there was very good technology used within the product ( for example the passticket technology), we are incorporating the best of what NetSP had to offer in our new Single Sign-On offering." The IBM Secure Single Sign-on product (based on DCE) is discussed in Chapter RACF Secured Signon Passticket The RACF Secured Signon Function provides an alternative, called a Pass Ticket, to the Resource Access Control Facility (RACF) password. The RACF PassTicket is a onetime-only and non-reusable password that is generated by a requesting product or function. It is an alternative to the RACF password that removes the need to send RACF passwords across the network in clear text. It makes it possible to move the authentication of a mainframe application userld from RACF to another authorized function executing on the host system or to the workstation local area network (LAN) environment. (IBM, 1994) A product or function that generates a PassTicket must use the RACF PassTicket generator algorithm. The algorithm requires specific information as input data and produces a PassTicket that substitutes for a specific end-user RACF password. RACF uses the PassTicket to authenticate the end-user for a specific application running on a specific system that uses RACF for identification and authentication. Page 48 of 173

56 3.8.1 Generating the PassTicket There are two ways to generate a PassTicket using the algorithm: If the function using the secured Signon capabilities is running on an MVS system, you can use the RACF Secured Sign-on callable service to generate the PassTicket. If the function does not reside on MVS, a program can be created which incorporates the algorithm. The fact that the passticket generator algorithm is available, makes it a suitable vehicle to achieve single sign-on on various platforms, as long as RACF is used as the Authentication Server.(IBM,1994) 3.9 Secure Tokens The most common secure token available today, is the Chipcard or Smart Card. Secure tokens facilitate SSSO in three ways: Because a secure token is physical and cannot easily be reproduced or copied, it mitigates the potential exposure created by SSO, by having a single userid and password have access to all the authorized resources in the enterprise for that specific userid. The secure token ensures that only the holder of the token, if he has the correct password or PIN, can gain access to the system. Smart Cards can be used as Tamper Resistant Security Modules (TRSM's) to securely store the user's UserlD, password and encryption keys. These keys can be securely downloaded and used for confidentiality, integrity and non-repudiation services. Encryption keys are typically complex and cannot be easily remembered by a user. Smart cards provide a secure and convenient way of storing these keys. In addition, the role -profile for the user and ACL data can be stored on the token. This allows off-line authentication and access control, in on-line situations, removes the need to download user profiles every time. User profiles are downloaded only if the profile has changed. (IBM SSSO, 1994) The built-in capability of Smart Cards to perform DES encryption, and in some cases, RSA encryption in a secure hardware module, enables other technologies like RACF PassTickets or Kerberos to be used to generate tickets or certificates. This ensures that no password needs to be sent in the clear over the network. These tokens can also be used for application data encryption and other security services. (IBM SSSO, 1994) 3.10 The Generic Security Service Application Program Interface (GSS- API): Introduction GSS-API The Generic Security Service (GSS) is an API which allows: Page 49 of 173

57 distributed applications to incorporate and use security services provided by any number of cryptographically secured protocols, the integration of a variety of security services including one-way and mutual authentication, message integrity, and message confidentiality into distributed applications secure sign-on to target systems to be implemented as part of an overall single signon solution. (Stan ley,1996) GSS-API Services The Generic Security Service Application Program Interface (GSS API) provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. The specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other related specifications: documents defining specific parameter bindings for particular language environments, documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services. A typical GSS-API caller is itself a communications protocol, calling on GSS-API in order to protect its communications with authentication, integrity, and/or confidentiality security services GSS-API Tokens and Security Contexts A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system. The peer passes the received tokens to its local GSS-API implementation for processing. The security services available through GSS-API are implemented over a range of underlying mechanisms based on secret key and public key cryptographic technologies. The GSS-API separates the operations of initializing a security context between peers, from the operations of providing per-message data origin authentication and data integrity protection. It also support a selection of confidentiality services as a caller option. The GSS-API defines an interface to cryptographically implemented strong authentication and other security services at a generic level which is independent of particular underlying mechanisms. GSS-API provided services can be implemented by secret key technologies or public key approaches. The GSS-API is independent of the Page 50 of 173

58 communications protocol suites with which it is employed, permitting use in a broad range of protocol environments.(rfc 1508,1993) GSS-API clients are not constrained to reside within any Trusted Computing Base (TCB) perimeter defined on a system where the GSS-API is implemented; security services are specified in a manner suitable to both intra-tcb callers. Tokens are data elements transferred between GSS API callers, and are divided into two classes: Context level tokens are exchanged in order to establish and manage a security context between peers. Per-message tokens are exchanged in conjunction with an established context to provide protective security services for corresponding data messages The internal contents of both classes of tokens are specific to the particular underlying mechanism used to support the GSS-API. Tokens are generated within the GSS-API implementation at an end system, and processed by the GSS-API implementation at that remote end system. Security contexts are established between peers, using credentials established locally in conjunction with each peer or received by peers via delegation. Multiple contexts may exist simultaneously between a pair of peers, using the same or different credentials. No correlation between security context and communications protocol association is dictated. This separation allows the GSS-API to be used in a wide range of communication environments, and also simplifies the calling sequences of the individual calls. The state information required for context setup can be sent concurrently with initial signed user data, without interposing additional message exchange. The GSS-API accommodates the concept of caller provided channel binding information, used by GSS-API callers to bind the establishment of a security context to relevant characteristics of the underlying communications channel and of protected mechanisms applied to the communications channel. Verification by one peer of channel binding information provided by the other peer to a context serves to protect against various active attacks. (RFC 1509,1993) The GSS-API facilitates portability from one security mechanism to another, but does not provide inter-operability across different security mechanisms. Application clients and servers that wish' to communicate securely are required to use the same underlying mechanism. (Stanley,1996) Page 51 of 173

59 The GSS-API has been implemented in a number of security mechanisms including Kerberos, DCE Security and SESAME Public Key or Asymmetric Cryptography Public-key cryptography may provide a basis for a new type of single sign-on solution. Although products are not yet commercially available, the approach offers some important advantages. Its potential should therefore be appreciated. To implement single sign-on using public-key cryptography, a principal creates a sign-on request using his or her private key. The target system uses the principal's public key to authenticate the request. Since private keys are long and not easy to remember, they must be stored on a smart card, workstation, or server. Regardless of where the private key is stored, it should be protected by encryption by a password known only to the principal. In this scenario, public -key single sign-on is similar to a trusted authentication server solution. However, there are possible implementations that do not rely on a server. To implement a public key solution without a dedicated authentication server, the private keys of principals are stored on smart cards. A desktop system generates a sign-on request that is passed to the smart card that is passed to the smart card to be encrypted with the user's private key. The encrypted request is then passed on to the target system. The target system can obtain the principal's public key from a directory service. The request is authenticated if the target system can decrypt the request with the principals public key. In this way the user is authenticated to the target system without using an authentication server - only a directory of public keys is required. If centralized security servers are to be entirely eliminated, then the access privileges and public keys of each user must be distributed to target systems. Currently, there is little experience with public key cryptography as a single sign-on solution and it is not yet clear whether it will be widely adopted. The outlook is further complicated by the restrictions that some countries apply to cryptographic techniques.(stanley,1996) Page 52 of 173

60 3.12 Summary In Table 4.1 below, some of the technologies described above, are rated in terms of security services that are provided: System tientidattob77 cress Non Kerberos orttrol udiatiom AA NetSP ( ) SPX TESS SESAME OSF DCE../ Table 3.1: Security Services Provided by the Systems [Oppliger,1996] Note: The brackets indicate differences of opinion, in NetSP's case whether a 40 -bit encryption key is sufficient for ensuring confidentiality, and in SESAME's case (Version 4), the author is of the opinion that non-repudiation is possible if the asymmetric cryptography option is used to authenticate a user Conclusion In summary, it appears that: DCE and SESAME provides more and better integrated security services; The DCE approach has the greatest market momentum and is now favored by IBM to replace the NetSp niche; The interest being shown by software products companies in DCE, starting with the database vendors (see Open Horizon, Chapter 6), is reinforcing this momentum; It is likely that SESAME will continue to have a strong influence, and that DCE and SESAME will converge; That both Kerberos and GSS-API will continue to play an essential role in SSSO solutions; Secure tokens will be essential to securely implement asymmetric encryption technology. Page 53 of 173

61 Chapter 4 4. OSF DCE 4.1 Introduction Open Software Foundation (OSF) Distributed Computing Environment (DCE) is one of the two open standards for distributed processing which are having a major influence on the development of single sign-on solutions. DCE consists of specifications and software. It has been termed 'middleware' or 'enabling technology'. It is not intended to exist alone and is not an application in itself. Rather, it is designed to be integrated with a vendor's operating system and used to build custom applications or to support software products, meaning products which incorporate DCE and conform to DCE specifications. (Stanley,1996) The goal of DCE is to turn a computer network into a single, coherent computing engine. As a layer of software that masks the differences among different kinds of computers, DCE sits on the top of the host and network operating systems, and offers its services to the applications above. DCE itself does not provide single sign-on. However, DCE has been used to create single sign-on solutions that interface with both legacy and newer systems that support DCE. DCE stems from work carried out under the aegis of the Open Software Foundation (OSF). OSF has now merged with X/Open and the combined organization remains heavily committed to DCE. It is most the most widely supported standard for secure distributed processing. The majority of computer vendors are providing DCE-based products. Many have DCE solutions for other vendors' platforms. In addition, database manufacturers, including Oracle, have stated their intention to move towards DCE compliance. A new version of DCE (V1.1) has recently emerged. A forthcoming version (V1.2) will provide public-key based sign-on. It is being specifically designed to facilitate the use of smart cards containing users private keys. Alternatively, it will be possible to hold a user' private keys in encrypted form on a server. Future releases are expected to enable the use of public keys to support single sign-on without a central authentication server. Page 54 of 173

62 4.2 OSF DCE Architecture DCE consists of multiple components that have been integrated to work closely together. A key component is the Security Service. This uses the Kerberos authentication protocol, with enhancements included to provide scalability and a wider range of services. Thus, a highly -influential development in secure single sign-on is at the heart of DCE. The Security Service is a required component in any DCE implementation and is part of what is referred to as DCE's 'secure core'. (Stanley,1996) DCE is constructed on a layered architecture, from the most basic providers of services (e.g. operating systems) up to higher end clients of services (e.g. applications). Security and management are essential to all layers in the model. Currently, DCE consists of seven tools and services that are divided into fundamental distributed services and datasharing services. The fundamental distributed services include threads, RPCs, directory service, time service and security service. Data Sharing Services build on top of the fundamental services and include DFS (Distributed File System) and diskless support. The OSF has reserved space for possible future services, such as spooling, transaction services, and distributed object-oriented environments. 4.3 Security services In DCE, an administration domain is called a cell. A DCE cell consists of a group of users, systems, and resources that have a common purpose and share common services. It typically consists of nodes in a restricted geographic area, but geography does not necessarily determine the boundaries of a cell. Factors that can also determine the boundaries of a DCE cell include the organization's size, its network topology, as well as its needs and preferences. In a decentralized and distributed environment, it is important to be able to locate resources, to keep the systems synchronized, and to provide various security services. Consequently, Page 55 of 173

63 The OSF DCE Architecture Applications S e C Diskless Support Other Distributed Services (Future) Distributed File Services M a n a r t y Time Service Naming Service Threads Other Fundamental Services ( Future) RPC and Presentation Services Operating System and Transport Services e m e n t Figure 4.1: The OSF DCE Architecture (Millikin.1996) DCE provides a set of integrated services that work across multiple systems and remain independent of single systems. The core DCE services are: A directory service; A distributed time service (DTS); A security service. At a minimum, a DCE cell configuration must include these core services. Distributed application clients usually find their application servers by looking up information posted in a directory service. Application servers determine the authenticity and authorization level of clients by using highly protected information from the security service, and the security service uses time information from the DTS to limit the lifespan of security-related information. Page 56 of 173

64 4.3.1 Additional Services In addition to the three core services, a typical DCE cell configuration also offers additional services, such as a distributed file service (DFS). All DCE services are integrated with DCE Threads and RPC: Threads. Traditionally, applications deal with processes, each of which has a single thread of control. In this model, multiple tasks within applications are divided among multiple processes. Threads extend the process model to multiple threads of control that share a single address space and set of resources, A multithreaded program has decomposed a single program into multiple threads of execution. Threads are an important emerging model for expressing parallelism within a distributed environment. (Millikin,1996) The RPC. DCE makes use of Remote Procedure Calls (RPC's) as a mechanism for implementing distributed computing. The DCE RPC adheres to the local procedure model as closely as possible, while providing distributed aspects of applications. RPC's use consistent protocols and provide identical behaviour independent from the transport protocol it runs on Distributed File System The OSF DFS is intended to provide transparent access to any file sitting on any node on the network (security permitting). It is based on AFS (Andrew File System) from Transarc and uses four principal components to address these needs: the DCE logical file system, a protocol exporter (file server), a cache manager (client), and a token manager. The implementation of DFS is a good example of how the various components of DCE work together. DFS software resides on each node on the network. DFS integrates the node file systems with the DCE directory services, ensuring a uniform naming convention for all files stored in DFS. It uses the DCE security system, with ACLs to control access to individual files. The RPC streaming function allows DFS to move large amounts of data through a WAN in one operation rather than dribbling it across in smaller packets. DFS uses a token management scheme to coordinate file modification. This prevents unintentional corruption of distributed files through multiple out-of-sync updates. DFS allows system administrators to subdivide filesystem partitions into filesets (logical collection of files). Filesets make it easy for administration of disk capacity, by enabling the administrator to move filesets from one partition to another. (Millikin,1996) A DCE client host is a DCE host that runs an application client or an application server but does not run a DCE server. Similarly, a DCE server host is a DCE host that Page 57 of 173

65 Single Sign-on In Heterogeneous Computer Environments runs one or more DCE servers. A DCE client host has the necessary DCE client software to interact with DCE servers and other DCE client in the cell. 4.4 The DCE core services: Directory Service One challenge that arises from distributed computing is the need for a universally consistent way to identify and locate resources. The usual approach to address this challenge is to use a directory service. A directory service is much like a telephone directory assistance service that provides a phone number when given a subscriber's name. Given a unique name of a resource, it is up to the directory service to return the network address of the resource along with other information related to the name UUID In DCE, universal unique identifiers (UUlDs) are used to uniquely identify resources, and the DCE Directory Service is to store and manage these UUIDs as well as to control the naming environment accordingly. The DCE directory service includes both A cell directory service (CDS); A global directory service (GDS). The CDS controls the naming environment inside a cell, whereas the GDS controls the naming environment outside and between DCE cells. The CDS can access a name in another cell using either of the global naming schemes (GDS or DNS). The GDS is an implementation of the ITU-T X.500 directory service, whereas the Domain Name Service (DNS) is another name service that is deployed widely within the Internet community Distributed Time Service Clock synchronization is a fundamental requirement in computer networks and distributed systems. The DCE distributed time service (DTS) supports clock synchronization within a DCE cell. The DTS itself is a RPC-based client/server application. DTS clerks interact with DTS servers, relieving client applications from this work. Each host that is not a DTS server has at least a DTS clerk. Because no device can measure the exact time at a particular instant, DTS servers and clerks express the time as an interval containing the correct time. Clerks obtain time intervals from several DTS servers and compute the intersection at which the intervals overlap. They adjust the system clocks of their client systems to the midpoint of the computed intersection. Page 58 of 173

66 DTS servers servers synchronize themselves by obtaining time information from all other DTS servers within a cell. Like clerks, servers also compute the intersection at which intervals overlap and adjust their host clocks to the midpoint of the intersection. Although the DTS ensures that DCE hosts share a consisten notion of time, this time need not be the correct time according to external time standards. 4.5 Security Service Similar to other distributed environments, security services must be built into DCE applications so that clients can call local security routines to acquire credentials that may be passed to servers, and servers can call security routines to verify these credentials. The DCE security service comprises three security services: An authentication service; An authorization or privilege service; A registry service Authentication Service In DCE, principals are users, servers, cells, and hosts. Users are principals because the identity of the user that initiates an action, such as an RPC call, is needed to determine whether access should be granted. Servers are principals because they need to authenticate the client that initiates an action on the user's behalf, and because the client may want to authenticate a server, too. Cells are principals because two cells can exchange secret keys to support intercell authentication. Hosts are principals too, because there are cases where they must authenticate the DCE security service itself. The fact that hosts are considered as principals in DCE is one of the major differences between the Kerberos and DCE security model. Every principal has a principal name. The DCE authentication service is able to interpret both DCE principal names and Kerberos principal names. Kerberos used UDP/IP while DCE in addition uses DCE RPS for communications. Since DCE version 1.1, the GSS-API is supported to allow non-rpc applications to use DCE authentication and authorization, too Authorization Service With regard to the DCE authorization or privilege service, the OSF has adapted a SESAME-like approach: privilege attribute certificates (PACs) are issued by a dedicated server to carry the principal's security attributes that are used to make access control Page 59 of 173

67 decisions. The security attributes of a principal basically consist of the principal's identity and some group-related information. In the DCE PAC, an authentication flag shows whether the certificate is authenticated by the DCE security service. This flag is necessary because, in principle, clients can also supply unauthenticated PACs. The PAC also contains the home cell UUID and the principal's UUID. The rest of the PAC describes the various groups to which the principal may belong. Although a distinction is made between local and foreign groups, only local groups are currently supported. The Kerberos V5 Ticket Granting Ticket (TGT) has a reserved field for authorization, which can be used by DCE to place a PAC. When a client receives a TGT with an empty authorization data field, it is up to the client to have the DCE authorization service place a PAC in the field. A TGT with a PAC in its authorization data filed is called a privilege ticket granting ticket (PTGT). In DCE, a discretionary access control (DAC) policy is enforced by using access control lists (ACLs). The cryptographic protocols that DCE implements are basically the same or authentication as Kerberos V5 and a SESAME-like enhancement for PAC-based authorization. With PAC-bases authorization, a user logs in just like in normal Kerberos or DCE with name-based authorization. The client, acting on the users's behalf, gets an ordinary Kerberos TGT with the user's name inside. The client then asks to be provided with a ticket for the PS. Equipped with the corresponding ticket, the client can contact the PS. The PS extracts the user's name from the ticket, look up the user's UUID and group membership, and requests a TGT from the KDC with the PS' name in the client name field. As previously stated, this is called a PTGT. The PS then returns to the client the PTGT and the corresponding session key instead of the original TGT. From now on, the client can use the PTGT instead of the TGT. Afterwards the client can use the PTGT to request as may PT as he needs. The remaining steps to request a ticket and to authenticate to the corresponding server are essentially the same for both name-based and PAC-based authorization Registry Service The registry service maintains a database of all the principal, group and account information for a DCE cell, as well as information about the cell itself. The Kerberos reference implementations from MIT have traditionally integrated network applications, such as telnet, rlogin, and ftp, to achieve a single sign-on facility in a network environment. While earlier versions of DCE have not followed this example, DCE version Page 60 of 173

68 1.2 is expected to correct this and will also be able to support public key cryptography for login. (Oppliger,1996) Based on this development, companies like IBM and Open Horizon are basing their Secure Single Sign-on solutions on DCE. 4.6 Conclusion Although OSF DCE is not a new technology, and its success was sometimes doubted, complementary technologies like Kerberos, SESAME and Public key cryptography has now matured to a stage where it can be implemented with DCE as basis. It can be expected that many vendors will design and build products based on OSF DCE and it could prove to become one of the most important technologies of the decade. Page 61 of 173

69 Chapter 5 5. SESAME Technology Version Introduction Secure European System for Applications in a Multi- vendor Environment (SESAME) project is a joint initiative by Bull (SA), International Computers Ltd (ICL) and Siemens Nixdorf InformationsystemeAG (SNI). The specification for SESAME Version 4, recently published on the internet (Parker, 1996), was used as the main source of reference for this chapter. The SESAME project was initiated in the wake of the European Computer Manufacturers Association (ECMA) work by the Commission of the European Communities (CEC). In its first stage, the project was required to develop the ECMA work into a demonstrable implementation, in order to show that the ECMA architectural ideas and principles were feasible and practical. This was achieved at the end of March The project then went on to a second stage in which it developed security components for use in the construction of commercial security products. The second stage led to the production of two intermediate versions, V2 and V3, which were released in July 1994 and June 1995 respectively. SESAME V2 and SESAME V3 were made freely available to selected pilot sites for non-commercial study purposes. Feedback from these studies has been influential in the development of SESAME V4. All of this work has been undertaken by Bull SA, ICL PLC and Siemens Nixdorf lnformationssysteme AG (SNI) under part funding from the CEC. The work of SESAME as a project has concluded with the current version: V4. The SESAME partners are intending to continue support and maintenance of this version, as well as developing further versions. SESAME is not in itself a commercial product. It simply provides the core security functionality upon which different vendors can build real products. Similar, but more specifically targeted work has been done by the Massachusetts Institute of Technology which has developed distributed authentication technology called Kerberos. Kerberos has been widely adopted; in particular, the Open Software Foundation's Distributed Computing Environment has merged the basic 'Kerberos functionality with architectural concepts originating in the SESAME project to produce an extended Page 62 of 173

70 form of Kerberos supporting some of the additional ECMA security concepts. (Stan ley,1996) In the light of this background, the SESAME project decided that in its early implementation some of the SESAME components would be accessible through the Kerberos V5 protocol, and would use Kerberos data structures, as well as new SESAME ones. This has shown that a product approach reusing selected parts of the Kerberos specification is workable, and that a world standard is possible incorporating features of both technologies. Another important development in the field of Open distributed system security has been the Generic Security Services Application Program Interface (GSS-API). This interface hides from its callers the details of the specific underlying distributed authentication and access control mechanism, leading to better application portability, and moving generally in the direction of a better interworking capability. SESAME supports the GSS-API base and some of the extensions. (Parker, 1996) 5.2 Platforms Supported Clients Domain Security Servers Servers Bull DPX 20 running AIX 3.2; Local Registration Authority SNI MX300i running SINIX (UNIX Server: Bull DPX 20 running AIX 3.2; SVr4); ' SNI MX300i running SINIX (UNIX ICL DRS6000 running UNIX System Bull DPX 20 running AIX 3.2; Svr4); V release 4; SNI MX300i running SINIX (UNIX CL DRS6000 running UNIX System IBM RS6000 running AIX 3.2. Svr4); V release 4; PC compatible, running Windows ICL DRS6000 running UNIX System IBM RS6000 running AIX X. V release 4; IBM RS6000 running AIX 3.2. Certification Authority Agent Server (Floppy disk needed): Bull DPX 20 running AIX 3.2; SNI MX300i running SINIX (UNIX Svr4); CL DRS6000 running UNIX System V release 4; IBM RS6000 running AIX 3.2. Certification Authority: PC compatible, running Windows Page 63 of 173

71 3.1.X. and supporting or providing.access to an ODBC (Open Data Base Connectivity) compliant database. (Parker, 1996) 5.3 General Description SESAME supports access control, communication integrity and communication confidentiality, and offers the means to ensure that access to services is policed to the appropriate level of security. Remote applications taking advantage of SESAME technology are accessible using a single point of sign-on, at which the user authenticates only once. It is not only a human being who may be controlled in this way (or an application acting on a user's behalf) but also an application that may be acting on its own behalf; both are referred to as "initiators" in this paper. SESAME achieves this by means of a sophisticated access control technology which supports Kerberos authentication protocols with some security extensions, and an ECMAstyle Privilege Attribute Service. The Authentication Service extensions provide support for authentication based on public key technology - principals may authenticate using their private key. After successful authentication by an Authentication Server (AS), the initiator obtains a ticket which he can present to a Privilege Attribute Server (PAS) 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 , the Access Control Framework. Once the initiator has selected a target application, it is given keying information. This keying information is composed of two parts: one part to secure the exchange of the PAC (and related security data) in order to prevent anybody but its genuine owner or an authorized delegate making use of it; another part to either integrity protect or confidentiality protect, or both, user data passed in a dialogue between an initiator and a target. Depending on whether the target makes use of asymmetric or symmetric key technology for key exchange purposes, this keying information is either fully constructed by the initiator or constructed with the assistance of a Key Distribution Service. The PAC and the keying information are then presented by the initiator to a target application whenever access to a protected resource is requested. The target application is now able to make an access control decision according to the initiator's security Page 64 of 173

72 attributes and the access control information attached to the controlled resource. PACs can be used at more than one target, and are signed by the PAS using public key cryptographic techniques. Provided the initiator permits it, PACs can also be delegated. Server Figure 5.1: Simplified View of the SESAME Model The infrastructure needed to support this architecture is composed of servers providing the services identified above: an Authentication Service, a Privilege Attribute Service and a Key Distribution Service, and servers that provide the background functions necessary to handle signed Directory Certificates needed for the asymmetric cryptographic functions: the Local Registration Authority (LRA), the Certification Authority Agent (CAA), and the (off-line) Certification Authority (CA) itself 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 minimize the use of encipherment by ensuring that it is used only in the most appropriate places, such as the protection of keys. Wherever possible, security control data exchanged is protected Page 65 of 173

73 against modification by tamperproof sealing rather than encipherment (the exception to this is when standard enciphered tokens conformant to Kerberos are used). In addition however, any user data may be optionally confidentially protected when requested by either the initiator or the target. The strength with which confidentiality of user data is provided can be configured to be different from that used for the protection of keys. This is to enable SESAME code to be exported to those countries in which the confidentiality of data is a concern. (Parker, 1996) Authentication and Single Sign-on SESAME supports single sign-on with two different authentication methods, either: the password based authentication mechanism defined in Kerberos (Steiner, 1988), or, an authentication method using asymmetric cryptography (i.e. public key technology) Pull versus Push SESAME supports the push model to obtain Privilege Attributes or Initiator Access Control Information (Refer to Chapter 2, paragraph for more information on the advantages of this approach) On-line versus Off-line Security Servers SESAME uses on-line security servers, taking the view that in business some form of immediate management control is important. This is particularly true for the management of initiators, which can be a rather volatile population. Because of this, and because initiators are also usually the main source of security risk, they need to be under permanent control, so that changes can be reflected immediately. For the management of keys for targets, SESAME is flexible as it either mandates the use of a Key Distribution Service or allows the use of Directory Certificates containing the public key associated with the target application. In the latter case, calls to the on-line Key Distribution Service are no longer necessary, though this approach requires the ability to access a repository of certificates (e.g. the Directory). Page 66 of 173

74 _Single Sign-on in Heterogeneous Computer Environments Heterogeneity of Privilege Attributes SESAME is not a proprietary development; it has its roots in the standards work of ECMA. It 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 has been extended from an original specific implementation on a distributed UNIX system. 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 sets of Privilege Attributes for each of these end-system types simply because they handle the same global values in different ways. SESAME solves this problem by utilizing standard Privilege Attribute types as defined by ECMA, which are independent of specific end-system representations but can be mapped into them as appropriate in the receiving system. This leads to better interworking potential as well as easier management of Privilege Attributes. When a SESAME user is granted membership of a group, it is represented once as a Privilege Attribute in this global form. Facilities are provided in the target system for an application to extract this value exactly as it was received, enabling it to use it directly in access control decisions. This has 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 values, not local values. In SESAME, PAC Privilege Attributes are not mapped onto target operating system values such as UNIX UlDs or GIDs, though there is no reason why the target application could not do that itself if policy dictated it Uses of Identity SESAME supports three of the separate types of identity attributes (refer to chapter 2), namely: Sign-on Identity, Access Identity, and Audit Identity. The names that have been chosen for the identity attribute types that are directly supported in SESAME are as follows: Authenticated Identity, which in SESAME is the identity held in the ticket obtained from the Authentication Server. This is used for "Access to Privilege Attributes", Page 67 of 173

75 Single Sign-on In Heterogeneous Computer Environments Access Identity, which is used in PACs for "Access". In SESAME this attribute reflects a value given by the PAS administrator, Audit Identity, which is used in PACs for "Audit". In SESAME this is a separate field in the PAC, which reflects a value given by the PAS administrator, Identities used for charging (Charging Identifier) and non- repudiation (Non-repudiation Identity) are not explicitly supported in SESAME, though they may be included in PACs as administrator-defined attribute types Roles SESAME directly supports real world access control policies that are based on the concept of a user's organizational role or job Access Paths and Delegation SESAME supports the simpler form of delegation (see chapter 2), with delegates not being able to further restrict the Privilege Attributes in the delegated PAC or the targets for which they are valid, beyond the limits placed by the original owner of the PAC. However, the protocol does allow for the future support of traced delegation without having to be changed Security policies and security domains In SESAME, two different classes of security authority are considered: off-line authorities and on-line authorities. Since the major role of off-line authorities is to issue Directory Certificates they are called Certification Authorities (CAs). The role of a CA is primarily to guarantee the association between the value of a public key and an element. This is acceptable when changes are seldom and revocation can be planned in advance. This is typically the case for public keys associated with target applications or security servers. SESAME allows a target application to be placed under the control of either an off-line or an on-line authority for key management purposes. The choice depends on several conditions, in particular: whether it is desirable or not to let the target application be accessed directly or to enforce the mediation of an on-line Key Distribution Server (KDS), Page 68 of 173

76 whether public key technology or secret key technology is chosen since off-line authorities only handle public key techniques. In SESAME, for a target application to be accessible as a member of a security domain, it needs to be associated with a PAC Validation facility (PVF). Each PVF has a long term cryptographic key, associated with it, either a secret key shared with the KDS of the security domain or a private key guaranteed by a CA. In the latter case, a CA provides a Directory Certificate for the PVF. Some on-line authorities, for some of their activities, are also under the control of off-line authorities, i.e. the PAS and sometimes the KDS (when it is using asymmetric keys for interdomain working). Thus some elements belong to more than one security domain since some of their activities are managed by different security authorities. 5.4 Basic components of the SESAME Model SESAME can be modeled in terms of several independent trusted third party (TTP) components, initiator components and target components. The TTPs are further differentiated between on-line and off-line authorities. The paragraphs that follow describe all of these components in more detail. 5.5 Trusted Third Party Components On-line authorities There are four trusted on-line authorities and one on-line untrusted service. The authorities are: the Authentication Authority; the Privilege Attribute Service Authority; the Key Distribution Authority, and the Local Registration Authority (LRA). The on-line untrusted service is the Certification Authority Agent (CAA). Their respective roles are as follows: the Authentication Authority authenticates principals acting as initiators; Page 69 of 173

77 the Privilege Attribute Service Authority certifies access privileges of principals acting as initiators; the Key Distribution Authority provides keys to principals, acting either as initiators or targets, to protect the exchange of security information. From these keys, others may be derived for use in securing the operational exchanges authorized by PACs. User Sponsor APA Client AS SMIB Audit CIDKM) V V v 4 PAS Domain Security Server KDS A CLRe CatTA--) CA SACM PVF SACM Protocol Handler Protocol Handler SESAME core components Components out of scope of SESAME -C C> 4 Sockets Local connection Communication Protocol Figure 5.2: SESAME Component Overview The LRA is the authority from which entities may request the generation of asymmetric key pairs. The CAA receives and responds to such requests when forwarded from (and therefore authorized by) Local Registration Authorities. The CAA communicates with the (off-line) CA. The CAA acts as a request collector and spooler. It cannot manipulate requests in any way because they are signed by the requesting LRA. Each authority (and the CM) is implemented as a server, and this leads to the recognition of the following components: the AS, the PAS, the KDS, the LRA and the CAA. In SESAME the AS, PAS and KDS of a given domain are supported on the same machine, and are together referred to as the Domain Security Server. Page 70 of 173

78 Off-line authorities SESAME uses Guarantors or Certification Authorities (CA), trusted to guarantee the public key of a principal (either an initiator or a target). SESAME does not support hierarchies where the guarantor may have a public key of its own which is further guaranteed by a second guarantor and so on. In SESAME, the CA file transfer with the outside world (CAA) is performed using a removable medium (e.g. a floppy disk) supported by both the machine supporting the CAA and the machine supporting the CA. The prime use of the Directory Certificates in SESAME is in the validation of the public keys of PASs and KDSs, but when initiators or PVFs possess public keys, they are also used in the validation of these keys. Multiple CA's are supported but cross- certificates between CA's are not. A Domain Security Server contains an AS, a PAS and optionally a KDS (Interdomain Servers are not supported). However not all of these need be present. A security domain supporting both principals acting as initiators or as targets makes use of all the servers previously identified. A security domain which only supports target applications would not need the AS and PAS components. It would even not use a KDS if target application PVFs are given (public) keys by a CA. Certification Authority OFF-LINE Local Registration Authority Certification Authority Agent (included for completeness but not trusted) ON-LINE Authentication Authority/Server Privelege Attribute Authority/Server Key Distribution Authority/Server Figure 5.3: The Basic TTP Components For the generation of asymmetric key pairs, an LRA needs to be present. This will typically be in the same domain as the key pair requester, though it need not be. Also, a Page 71 of 173

79 Single Sign-on In Heterogeneous Computer Environments CM associated with a CA must be established. A CAA or CA need not be in the same domain as the LRA; indeed, they may serve several security domains. When the target application is given a secret key from its KDS, then the main addition which is needed is that the KDS of each domain must be given a private/public key pair certified by a CA Initiator Components There are three main Initiator components: the User Sponsor (only present when the principal is a human entity) which is the interface of the user with the system, the APA Client which is the interface with the AS and PAS, and the initiator end of the distributed Secure Association Context Management (SACM) component, which is the interface with the PAS and the target end-system Target Components There are two main target components: the target end of SACM which is the interface between the target application and the initiator machine, and the PAC Validation Facility (PVF) which is a trusted piece of code used by the target SACM to validate the PAC, get the PAC contents and get the keys to secure the subsequent conversation with the initiator. 5.6 Trust Model The security of SESAME is built upon several chains of trust involving the components discussed above. The initiator components and the target components are respectively trusted by their principals and their target applications. From an initiator perspective, an initiator application in SESAME is acting either on behalf of a human user or on its own behalf. Each human user principal is given a sign-on name so that it can authenticate to an AS. It is also given an authenticated identity which can then be recognized by a PAS. It can then obtain from a KDS the keying information to be used to secure exchanges with target endsystems. Hence there are two links in a chain of trust: one to get a PAC and one to get the keying information. The first link is where the PAS trusts the AS to authenticate the Page 72 of 173

80 principal correctly. The second link is where the KDS trusts the PAS to provide the proper protection for performing the key request. From a target perspective, a target application is "sponsored" by a PVF. Each target application is given a name and is associated with a PVF. Each PVF knows the name of the applications it supports. A PVF is either sponsored by a KDS or by a CA (the first case applies to the use of a shared secret key between the PVF and the KDS that the PVF trusts, while the latter applies for the use of a public key for the PVF). The association between the name of the PVF and the name of the target application is established and maintained by the guarantor of the PVF. The SESAME KDS can also hold application names directly, in order to provide support pure Kerberos clients making requests for tickets. The KDS can detect when its client is a SESAME one or not, and act accordingly. This aids migration from Kerberos to SESAME. Each PVF also identifies the names of the PASs that it globally trusts. Thus, it is not possible to specify that for one of the PVF's applications a certain PAS is trusted, but for another a different PAS. A target application trusts its PVF. The administrator of a PVF is thus able to enforce the security of a target application provided that he has been allowed either to register the PVF with a target KDS or to obtain a Directory Certificate from a CA trusted either by an initiator or by the initiator's KDS. The authority of the KDS or the CA administrator over that PVF's applications is thus partly delegated to the PVF administrator. The content of the PAC and PAC controls are released by the PVF only if the authority that issued the PAC is trusted by the PVF. Access may be granted if both the PAC and the keying information are acceptable to the PVF. The PAC can be trusted if it comes from a trusted authority and if the Directory Certificate corresponding to the private key used to sign the PAC is valid. For symmetric or hybrid key distribution in the interdomain case, symmetric keying information will need to be processed by the KDS of the PVF. In this case, there is an extra link added to the trust chain: the PVF trusts its KDS which in turn must trust the KDS of the initiating domain. Page 73 of 173

81 5.7 SESAME's use of names SESAME uses a Kerberos conformant protocol for password based authentication, so SESAME principals are given Kerberos principal names. Moreover, the SESAME security domain is equivalent to a realm as defined in Kerberos, so Kerberos realm names are used to identify SESAME security domains. In SESAME, an entity that authenticates via a password is given a printable Kerberos principal name. 5.8 Directory Naming As described elsewhere, SESAME uses public key technology supported by Directory Certificates, so for this purpose SESAME entities are given Distinguished Names (DN's). SESAME provides an explicit mapping in a principal's Directory Certificate, using the extensions field of the extended Directory Certificate syntax to carry the principal's Kerberos name. 5S Cryptography and Key Management This section describes how cryptography is used in SESAME Algorithms Three kinds of cryptographic algorithm 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. This type of algorithm is used in particular to protect communication exchanges, either for integrity protection or confidentiality protection, asymmetric algorithms (sometimes called public key 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. In SESAME this type of algorithm is used for several purposes: Page 74 of 173

82 0 to achieve data origin authentication and data integrity of PACs, 0 for key distribution when the PVF supporting the application has a private key, 0 for key distribution between different security domains (optionally in conjunction with symmetric technology), 0 for signing Directory Certificates and requests for them. one-way algorithms, where it is possible to encrypt the data but where reconstructing the original data from the encrypted data is computationally intractable. This type of algorithm 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 to control the use of PACs, to integrity protect user data, and for calculating the keys used to protect the exchange of user data (known as dialogue keys). SESAME has been designed and developed so that algorithms can be easily replaced and key sizes adjusted according to local legislation or emergence of a better algorithm in the future. This crypto functionality is separated out into a special purpose Cryptographic Support Facility (CSF), replicated in each system. Unless the pure public key option for authentication or key management is chosen, support of public key operations is required only by three of the components (the Privilege Attribute Service, the PAC Validation Facility and the interdomain functions of the Key Distribution Service) Basic Keys and Dialogue Keys The exchanges between the initiator and target are secured using a two level key scheme in which a distinction is made between basic keys and dialogue keys. A basic key is a temporary key established between an initiating machine and the PVF of the target application. The basic key is used for integrity protecting the PAC, associated PAC control information, its own key establishment information in transmission and the information used to establish dialogue keys. In the target endsystem only the PVF ever learns the basic key. The basic key is established by means of the initiator sending keying information to the target in a construct called a basic key package which can take different forms depending on whether the initiator and target are in the same security domain or not. Page 75 of 173

83 A dialogue key is a temporary key established between the initiator and target, via their SACMs, to be used for protecting the user level operations 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 configured in to conform with local regulations. Dialogue keys are constructed from a basic key using a one way algorithm as described below. The integrity dialogue key is also used to authenticate the target application (via its PVF) to the initiator when mutual authentication is requested. The distinction between dialogue and basic keys enables the PVF to control whether dialogues between the initiators and targets can take place. The distinction also results in the protection of this dialogue being performed independently of the protection of the establishment of the PAC. A key derivation method involving unique numbers is used to generate dialogue keys. SESAME's unique numbers are numbers constructed by combining a random value with current date and time Key Management SESAME supports two approaches to Key Distribution. The first approach is to subcontract the construction of working keys (in SESAME's case, the basic keys) to a Key Distribution Service, which knows the long term keys of the other principals in its domain. The second approach is to provide long term private keys so that principals knowing the corresponding Directory Certificates can themselves build the working keys. For the construction of keys between domains, SESAME uses public key technology. There are two variants: either each Key Distribution Service that supports interdomain communication is supplied with a private/public key pair, or the PVF supporting the target application is supplied with a private/public key pair Cryptographic Issues Page 76 of 173

84 The SESAME architecture has been designed to address the problems of government control over cryptography and technologies subject to patents. 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). PACs are cryptographically signed, 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. PAC protection is provided using public key cryptography, 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 (DSA) could provide the necessary functionality instead of RSA SESAME Security Servers In SESAME, there are several security servers to consider: the Domain Security Server (AS, PAS and KDS), the LRA and the CA. The link between the LRA and the CA is the CAA, though this is not a trusted security server. Typically each SESAME security domain (if it supports key registration) has its own LRA, but CAM share the same security domain as the CA they are serving. The CA's security domain may not have any relation to SESAME domains The Domain Security Server Authentication Server (AS) Authentication of a principal is performed by the AS. SESAME provides two ways to authenticate: either using normal password authentication via a Kerberos conformant protocol, or using private key authentication. The AS maintains a database of principals with their authentication information. This database is administered by a security administrator. The authentication information maintained in the AS is either the public key of an application or a user, a true secret key for an application or a secret key derived from the user's password. Page 77 of 173

85 If the principal only possesses a password (i.e. it has no private key), in order to authenticate, it sends to the AS a clear-text request including its sign-on name and replay detection information. This results in the return of a PAS ticket and a session key encrypted under the secret key of the claimed principal. It is important to note that the AS does not know whether the principal requesting the PAS ticket is or is not really the named principal, so no true authentication has yet taken place. If the principal possesses a private key, then this key can be used to authenticate it. In this case, the AS does know that the principal is authentic, since the initial request is signed by the principal's private key. Having successfully authenticated the principal, the AS returns a PAS Ticket as for other forms of authentication, though it contains the reference number of the Directory Certificate used by the AS to validate the principal's private key. The PAS ticket includes the authenticated identity of the principal, which will be used by the PAS as the entry point to the database to get the access privileges of the user. Page 78 of 173

86 SESAME Domain I SESAME Domain Figure 5.4: Different Security Servers and Security Domains Privilege Attribute Server (PAS) A principal's access rights are known in SESAME as access privileges. These are stored in the form of Privilege Attributes in a PAS. The responsibilities of the SESAME PAS are: to manage principals' access privileges, to deliver signed PACs (along with other control information for those PACs that are to be delegatable) describing client principals' access privileges and their usage restrictions on request of the client, Page 79 of 173

87 to provide cryptographic keys in KDS Tickets for use by its clients to protect subsequent communication with a Key Distribution Service from which they can obtain keys for communicating with target applications. Operations on the PAS are integrity protected by a key that the client is expected to obtain by authenticating itself to an Authentication Service. The PAS ticket is effectively being used as a proof of authentication. The choice of PAC is made by the caller specifying that it requires either default privilege attributes, or attributes corresponding to a role name, or specific explicitly nominated attributes. The role name not only determines which privilege attributes go in the PAC, but also the targets the PAC is to be valid for and whether the PAC is to be delegatable. Local SESAME core components used by the PAS are: A Public Key Management (PKM) facility to get the PAC's private key used for signing the PAC, as well as the corresponding Directory Certificate. A Cryptographic Support Facility (CSF) to handle communications security operations, to sign PACs and to encrypt the PAC's CV when present Key Distribution Server (KDS) A KDS is used to build basic key packages for targets that possess secret keys. The responsibilities of the Key Distribution Service (KDS) are: to deliver cryptographic keys (basic keys) to be used with the PVF of a target application, to manage long term secret keys shared with the PVFs of the target applications in its security domain, to manage the mapping between target'application names in its security domain and their PVFs, in support of interdomain working, to make use of the public keys of the KDSs in other security domains after verifying their validity, Page 80 of 173

88 Single Sign-on In Heterogeneous Computer Environments A KDS request will be granted only if the request includes a KDS Ticket. The SESAME KDS Ticket always includes a PPID value which is used for the protection of nonproxiable PACs. The PPID is subsequently blindly copied into the basic key package by the KDS. SESAME supports two schemes, one for intra-domain working and one for interdomain. SESAME core components local to a KDS are: a Cryptographic Support Facility (CSF). The KDS uses this to decrypt a KDS Ticket, to handle communications security operations, to integrity protect the basic key packages and to encipher the basic key, a Public Key Management (PKM) facility. The KDS uses this for interdomain operation to get the public key of a remote KDS, to use this key to encrypt the intermediate key mentioned above, and to use its own private key to sign basic key packages Security Management Information Base The Security Management Information Base (SMIB) is the database of the Domain Security Server. It stores all long term security data needed for the AS, the PAS and the KDS to build security data constructs. In SESAME it is a set of local files. These files are not directly visible since the SMIB database is always administered using a Control Program (SESADMIN). SESADMIN allows the administrator of the security domain to specify the authentication mechanism (secret or public) and, when meaningful, the secret key of a principal. For PAS management, the administrator can specify a user's privilege attributes, his allowed role names and the default role name attached to each known user, and the set of privilege and target control attributes associated with each role name defined in the domain. The administrator can also specify well-known privileges (i.e. access id, primary group, secondary group, role attribute) or miscellaneous (i.e. audit id) attributes as well as any other attributes he wish to use, including ones defined by himself (all attribute types are identified by an Object Identifier). For interdomain working, additional information needs to be managed. It consists of: trust relationships between KDSs. Page 81 of 173

89 the private key of the KDS and its associated Directory Certificate produced by a CA Public Key Management Servers Public key management involves the co-operation of three servers: the CA, the CAA and the LRA. Floppy End User Requesting Key Pair Local 1 Certification Registration Authority Authority Agent Certification Authority Figure 5.5: The SESAME Public Key Management Process The Certification Authority (CA) A CA produces Directory Certificates upon presentation of a public key and a distinguished name (and some other associated information). For security reasons, a CA works off-line and thus is not accessible directly from the network. A CA is under the control of a CA administrator. The CA processes files obtained from the CAA. It uses preset criteria to determine which requests can be satisfied automatically and which are to be held over for a human decision. In particular, it is possible to specify the different name structures that are to be allowed to be presented by each individual LRA for automatic processing. In SESAME, the CA is supported by a PC compatible machine supporting MS-Windows. All functions are available via a Graphical User Interface The Certification Authority Agent (CAA) Page 82 of 173

90 The CAA server is on-line. It acts as a bridge between the on-line LRAs and the 'off-line CA. Looked at from the CA's point of view, it provides data to and receives data from the CA administrator. Looked at from the LRA's view it acts both as a spooler of signed requests to the CA, and an agent for the supply of key pairs certified by the CA. On the CA side, the CAA administrator provides the CA administrator with a file containing the LRAs' requests for Directory Certificate creation. The CAA administrator receives from the CA administrator the requested certificates. All functions are available via a Command Line Interface The Local Registration Authority (LRA) Users must contact their LRA administrator in order either to get a private key and a Directory Certificate containing the corresponding public key. When a user requests a key pair, the administrator authorizes the LRA to generate it and send the public key associated with the user name, along with other information, to the CAA. This is all protected under the LRA's digital signature. When the Directory Certificate is returned to the requesting LRA, the LRA administrator provides the user with the certificate and the corresponding private key encrypted under a symmetric key-encrypting-key. In SESAME, this key is a password issued for the purpose by the LRA administrator. The LRA supports other functions like viewing and archiving the list of requests and responses sent to or received from the CAA. All functions are available via a Command Line Interface The end-user An end user may request a key for himself or for another entity (e.g. a PVF). Thus the LRA administrator records the name of the entity for which a Directory Certificate is requested together with some free text which is transmitted up to the CA. This free text may be used for example to record the name of the end user who should receive back the key, when the key is for a server (e.g. a KDS, PAS or PVF) Initial keys The CA administrator may establish a key pair for its CA. In the same way each LRA administrator may establish a key pair for its LRA. Each (uncertified) public key may be exported on a file (using pkmcp cache export). The CAA administrator is not provided Page 83 of 173

91 with a key. The administrators have to exchange the files using out-of-band means (e.g. by meeting physically) and thus can exchange the public keys. Requests coming from the LRA are signed and include a time reference. Responses coming from the CAA are signed by the CA Generic Components Three of the major pieces of SESAME functionality are required in a number of different places within the implementation. This section describes these components and the interfaces they support, all of which are accessed as library routines Public Key Management (PKM) The PKM facility is used by client end-systems, by PVFs in target end-systems, by the PAS, and by the KDS when handling interdomain key distribution. It contains the functionality for handling Directory Certificates in support of public key operations. The SESAME PKM provides relatively simple functionality, but has been designed for easy extension to cover such things as support for hierarchic CA chain tracing Cryptographic Support Facility The Cryptographic Support Facility is responsible for providing all of the algorithmic cryptographic services needed by the other SESAME components and by SESAME supported applications. In particular in SESAME it provides: symmetric and asymmetric encryption and decryption, irreversible encryption, generation and verification of both symmetric and asymmetric cryptographic check values, symmetric key generation, asymmetric key pair generation, derivation of dialogue keys from basic keys. Every cryptographic operation is performed in relation to a cryptographic data protection context, which consists of: Page 84 of 173

92 a key, the key comes with associated keying information that may impose restrictions on what operations that key may be used for, a quality of cryptographic service (weak, medium or strong), a reversible algorithm and/or an irreversible algorithm. Supportive operations are provided to activate or deactivate the ability to use a particular algorithm, to create, delete, export and import symmetric keys and asymmetric key pairs, and to establish, delete, export and import data protection contexts. For the major algorithmic operations such as encryption, signature verification and so on, the CSF hides from its callers the details of the cryptographic keys and algorithms used, by simply expecting the caller to provide a data protection handle. In this way, different algorithms can be transparently substituted to satisfy local requirements. Algorithms supported and used in SESAME are MD5, DES-CBC, DES-MD5 and RSA. For export control reasons, the public version of SESAME uses, for the encipherment of user data, a simple key-dependent XOR function. Commercial versions of SESAME include, for the encipherment of user data, the DES algorithm and other algorithms Audit Facility Audit events are security relevant actions which occur in the system and which are worthy of recording for subsequent analysis. Audit events are logged via a write-only pipe to an audit daemon that runs under its own UID and which stores the audit information in audit records, one per event, in an audit file. The audit file is thereby protected from modification by application processes. In SESAME, the actual components that audit their activities are: the PAS, KDS, the PVF, the SACM client and the SACM server, and the APA Client. Retrieval and analysis of this information is out of scope of SESAME, since it is expected that separate tools will be developed to take advantage of these audit files. SESAME includes an audit application that can display audited events User Sponsor The user sponsor is the architectural component responsible for the user's interface to the system. In SESAME only a minimal command line User Sponsor is provided, supporting sign-on, logout and change of role. The view is taken that the SESAME User Sponsor will in practice be replaced by a vendor specific product component. Page 85 of 173

93 Single. Sign-on in Heterogeneous Computer Environments APA Client The APA Client is the architectural element used by the User Sponsor component to hide from it the details of the dialogues used to access the AS and PAS. In SESAME it is implemented as a library routine. The APA Client APIs are designed to be general enough to permit underlying implementation of a variety of authentication mechanisms, for example mutual authentication, and multi-step authentication processes such as challenge/response. Since SESAME sign-on is not combined with the local sign-on, there is a pre-requisite which is that the user is able to use the local system. When the local system is a Unix machine, it is required that the user is registered as a local UNIX user and has already logged on before being able to use the SESAME sign-on. This is not required when the local system is a PC Initiator Secure Association Context Management (SACM) The security properties of associations with target applications are handled at the initiator end by the initiator component of SACM. Initiator SACM is the component which supports the GSS-API on the initiator machine. In outline, initiator SACM is responsible for: managing the information related to the security contexts that are formed from the initiating machine, and providing its caller with the tokens needed to establish those contexts, automatically obtaining the credentials (i.e. PACs, PAC control information and keying information) for new contexts if they are not already available to it, by making suitable calls on SESAME security services, generating "dialogue key packages" to send to target PVFs (as part of the GSS-API tokens it creates), containing information from which the target PVF can derive confidentiality and integrity dialogue keys, if pure public key technology is in use for key management, SACM generates the key packages for sending to target systems. Page 86 of 173

94 Cache Handler This holds the security context information in a filestore cache. This information includes, where available, the list of applications for which a PVF is responsible. Thus having obtained a basic key for a particular application (i.e. for its PVF), if a request to access another application specifies one for the same PVF, the existing basic key can be reused External Interfaces User Command line interfaces and sign-on APIs Three command line utilities are provided for human users for SESAME. SESAME sign-on allows the user to enter a login name, a password and a role name. The role name will be used later by SACM for requesting the first PAC. Strong-sign-on supports authentication for users with private keys. The user just supplies his sign-on name here. It is assumed by SESAME that the user's private key has been deposited within the PKM component of the client machine by means external to SESAME. Change attribute is used by human users to change their role during a session. SESAME logout deletes the credentials associated with a principal from the local system. It is important to note that successful authentication can mean that a principal has been authenticated by an AS, but that there is (yet) no assurance that the AS is a genuine one. This assurance will only be obtained when an application which is really registered with a KDS is accessed later. One way to get this assurance is to build an association with a local "verification" application which shares a secret key with the domain KDS. In this case, the AS returns a certificate proving its own authenticity GSS-APIs Once authentication credentials have been obtained, they can be used to build security contexts. This call returns a GSS Token which needs to be transferred to the target application. The transfer itself is the responsibility of the caller. In theory, this API may be Page 87 of 173

95 called once or successively several times. This is mechanism specific but also dependent on whether authentication of the target application is needed prior to the sending of application data (i.e. mutual authentication). With the SESAME mechanism, if mutual authentication is not requested, only one call is needed, otherwise two calls are needed. The second call is used to process the GSS Token returned from the target as a result of the mutual authentication request. When authentication of the target application is not needed, and the GSS token and application data can immediately be sent together in the same exchange. However, it may be desirable to protect the application data either for integrity only or both for integrity and confidentiality. This allows two GSS tokens to be sent to secure connectionless protocol paradigms: one for establishing the privileges and the dialogue keys, another to secure the application data Walk-through This section describes how the SESAME components interwork in a typical user session. (Refer to figure 5.7 below) Client Machine Interactions: 1. The User Sponsor invokes the APA Client through an authentication API to authenticate the person, who specifies (or defaults to) the name of the role he wishes to use. The APA Client either invokes the authentication API which generates a Kerberos conformant authentication request to the AS, or engages in a strong authentication exchange. Page 88 of 173

96 Domain Security Server AS Security Management Information Base (SMIB) (A set of local Files) Role or t privilege I types I 4 PAS Attributes r 8 KDS Application's PVF seciet key Key to Arrows: LOcal Exchange Username & Auth. Info 1 APA Client Login API st 3 L 2 PAS Ticket Uset Sponsor (Login Program) User Name & Role & PAS Ticket 3 Cache Handling PAC & <DS Ticket 5 KDS Ticket & Appl Na -ne 7 Initiator SACM oasz121 t_e2c254iar15 4_19 Client Application Keying info & PVF Appl s Target End-system pss Token Server Application I GSS Token Initiator Machine Figure 5.7: SESAME Components - Initiator Machine View The AS builds a PAS ticket and returns it along with Kerberos control data to the APA Client. For password based authentication this a pure Kerberos action, but with a random PPID value inserted in the authorization data field. The APA Client stores the PAS ticket in a cache and returns to the User Sponsor. If strong authentication has been done, the PAS ticket contains a PPID whose value is the certificate identifier of the certificate used by the AS to do the authentication. A message is also returned to authenticate the AS to the user. If a role name was specified by the user, or if a default PAC regime is in operation, the User Sponsor passes this to the APA Client, which then requests an initial PAC from the PAS. This is done by invoking the initiator's SACM component. SACM uses the deposited PAS ticket, and the user's role name in the request to the PAS. The PAS decrypts the PAS ticket to get the key used to protect the dialogue between SACM and the PAS. If no initial PAC was specified, a PAC will be fetched later at step 7. The PAS reads the user name and the role name and verifies that the user is allowed to exercise that role. If the role name which has been given is not allowed, the system Page 89 of 173

97 Single Sign-on In Heterogeneous Computer Environments default role is used instead. The role name is used to access the privilege and target qualifier attributes associated with that role. The PAS then builds a PAC and signs it with its private key. Finally it builds a KDS ticket and encrypts it with a secret key shared with the KDS, putting in the PPID value obtained from the PAS Ticket. The PAS returns to SACM the PAC and the KDS ticket along with one or more optional Control Values (CVs) if the PAC is to be delegatable, and the Kerberos conformant control data accompanying the KDS ticket. This response is protected by the SACM/PAS basic key. CVs are used to control and protect the PAC in delegation. They are returned encrypted under the basic key. The PAS ticket, the PAC, CVs and the KDS ticket are stored in the cache by SACM. A user handling program can now access the attributes present in the PAC through the extended GSS-API (gss_get_attributes) so that, for example, the user can be informed of what privileges he is working with. Sometime later, an application based on GSS-API is invoked. The SACM component is invoked through GSS-API from the client application. If the PAC stored in the cache is not valid (if it has expired, or if special delegation controls are necessary) or not appropriate (e.g. a new role has been selected), or not present (there was no initial PAC requested), SACM requests a new PAC from the PAS (not shown in the figure). This is achieved exactly as described in steps 3 to 6. Next, a key for the application server is requested. When the PVF supporting the target application has been given a public key, then the Basic Key Package is an asymmetric one. Its computation is done locally, and it is built into a Basic Key Package protected under the target PVF's public key and the initiator application's private key. No KDS is involved. When the PVF supporting the application' has been given a secret key the Basic Key Package is obtained from the KIDS using the KDS ticket stored in the cache. Steps 8 and 9 below only exist in the latter case. The KDS constructs keying information on behalf of SACM. The keying information is returned to the SACM component. If the KDS knows them (i.e. when the target is in the same domain as the initiator), the KIDS also returns to the SACM component a list of other applications that the keying information is good for. SACM extracts from the keying information the basic key that it will use to protect the token to be sent to the target application's PVF. SACM must now encrypt the PAC's CV(s) (if present) with the basic key, ready for it to be confidentially sent to the target end-system. SACM also adds to the keying Page 90 of 173

98 information, information enabling dialogue keys to be shared with the target application. It then returns to the client application a GSS token comprising the PAC, the encrypted CV and the keying information. The GSS token is sent to the server application where it is checked by the application server components as described in the next section. 11 If mutual authentication was requested, and the GSS Token sent to the target was acceptable to the target, a mutual authentication GSS Token is received from the target, which initiator SACM then uses to authenticate the target. Note that this token is protected not under the basic key, but under the dialogue integrity key, and that therefore mutual authentication is only as strong as this key and its associated algorithm Target Interfaces and Components This section describes the collocated components involved in checking and accepting access from a remote initiator, their relationship to each other, and their use of remote SESAME security services Target Secure Association Context Manager (SACM) The security properties of associations with target applications are handled at the target end by the target component of SACM. Target SACM is responsible for passing the incoming security information to the PVF for analysis and validation. If all is valid, SACM receives from the PVF an integrity dialogue key, and a confidentiality dialogue key. These can then be used to protect operational exchanges between the initiator and the target application. The security context is not made available to the application if the PAC checks made by the PVF fail, but even if they succeed, SACM performs an additional access control check, as follows: The Initiator attributes used are the Access Identity and Role attributes, taken from the PAC. Access authorization rules are structured as a single set of entries in an "authorization block" structured as a set of Access Control List (ACL) entries. The protected objects are applications, to which access is either fully granted or totally denied. An entry can Page 91 of 173

99 specify a specific application or "all applications", to be accessible or not accessible by either an identity, a role, or "all initiators". User-specific (i.e. identity based) rights take precedence over role and general, permissions and prohibitions. This token is protected with the integrity dialogue key. Once a security context has been established, the application can then police specific access requests to objects protected by it by asking its SACM for the secure association context information that currently applies PAC Validation Facility The PAC Validation Facility (PVF) is a trusted piece of code used by the target SACM on behalf of the applications accessed through SACM. In SESAME the PVF is collocated with the applications it supports. Each target application in the end-system is associated with the single PVF in that end-system via its SACM. Thus, more than one application may be associated with a given PVF. The PVF runs in its own protected process and is accessed by inter- process calls. An application's SACM uses its PVF to handle establishment of basic keys, to validate PACs, to extract and return the information in the PAC that is applicable to this application, to obtain the dialogue keys under which its operational exchanges with initiator machine can be protected, and to provide the information and support needed to perform delegation operations with the PAC External Interfaces - GSS-API. The only external interface relevant in the context of a target machine is the GSS-API. A target application may process an incoming token as part of context establishment. With the SESAME mechanism, only one call is needed. If mutual authentication has been requested, the API returns a GSS Token which contains information to be carried back to the initiating application. The transfer of the GSS Token itself is the responsibility of the target application. Incoming application data may have been protected either for integrity only or both for integrity and confidentiality Interdomain Working Page 92 of 173

100 In SESAME, validly presented PACs from one security domain can be accepted directly by target PVFS in another security domain if the PAS of the originating domain is trusted in the target domain. A PAS is trusted if its Directory Certificate is valid, and if its public key is guaranteed by a CA trusted by the PVF. A PAC is recognized as being validly presented if one or more of the protection methods in the PAC passes the validation checks. There is no Interdomain Service in SESAME. Interdomain key distribution functions have been designed to take maximum advantage of single domain key management functionality, while adding the benefits of public key based capabilities Key Distribution This section describes in outline the protocols supported for establishing a basic key shared between an initiator and a target application's PVF, and the method of deriving dialogue keys shared between the initiator and the target application. The protocols are described in two sub-sections below Protocols that use a KDS These protocols make use of pre-installed long term keys as follows: A secret (symmetric) key, Kpk shared between a PVF and its KDS, For interdomain key establishment, a private (asymmetric) key, KnPR owned by each KDS. The protocols are designed to make maximum use of the service ticket structure defined in Kerberos, which has been used both in the intra-domain and inter-domain variants of the protocol Interdomain If TA is in a different security domain, KDS1 works out the name of the KDS of TA's domain (KDS2) by adding the SESAME defined KDS name prefix to the domain name. It then uses its local PKM facility to get KDS2's public key which it uses to encrypt a dynamically generated symmetric key (DESK) which in turn is used to encrypt the Ticket Page 93 of 173

101 for TA's PVF. This Ticket is otherwise a normal Kerberos]conformant service ticket as before. The Ticket and the encrypted DESK are put into a separate interdomain information construct which is signed using the KDS1's private key Protocol not requiring a KDS SESAME supports a method of establishing a basic key using only asymmetric crypto technology. Under this method there is no need to involve a KDS. The token structure is designed for maximum future interoperability potential with the Simple Public Key Mechanism (SPKM), i.e. the Basic Key Package contained in the initial token has the same ASN.1 structure. It is supported for initiators and target PVFs that both possess private reversible asymmetric algorithm keys, and can be used both within and between security domains The Privilege Attribute Certificate (PAC) This section describes the structure and contents of the PAC, how the contents are used and how the PAC can be protected PAC Structure The structure conforms to the definition of a security certificate described in [ISO ). The general form of a security certificate has three components : information common to all security certificates, realized in the Common Contents and Signature fields, security information specific to one or more security services (in this case access control), realized in the access privileges carried in the Specific Contents field, information to control and/or limit the use of the security information, realized in the protection methods and audit identity carried in the Specific Contents field. The individual fields of the SESAME PAC are described below: Page 94 of 173

102 Issuer Domain. The security domain of the issuing authority, always present in SESAME. It is in Directory Name Format. Issuer Identity. The name of the issuing authority. This is represented by the PAS's name within the security domain. Serial Number. A unique number for the PAC, allocated by the PAS. Creation Time. The UTC time that the certificate was created, according to the authority that created it. Validity. A pair of start and end times within which the certificate is deemed to be valid. Algorithm Identifier (in Common Contents). Used to identify the algorithm used to sign the PAC. Protection Methods. Fields used to control the use of the PAC. Privileges. The privileges granted by the PAC. All privilege attributes are associated with a defining authority, either explicitly by prefixing it with a defining authority field or by default. In SESAME only attributes with a defaulted defining authority are created. Miscellaneous (Audit Identity). The PAC owner's audit identity appears as a miscellaneous PAC field. No other miscellaneous fields are supported. Time Periods. Identifies one or more time periods outside which the PAC is invalid. In SESAME a fixed set of time periods can be specified for all PACs, but different times cannot be specified for different users. Value (of Signature). The PAC is digitally signed using an asymmetric algorithm (RSA in SESAME), by applying a message digest algorithm (MD5 in SESAME) to the PAC body and encrypting the resulting hash using the private key of the PAS. This field contains the result. Algorithm Identifier (in Signature). This field identifies the algorithms used above, but is not used in SESAME. Page 95 of 173

103 Certificate Information. This field may be provided to help PVFs receiving the PAC to validate the PAC signature. In the SESAME implementation, its presence is configurable by the PAS administrator. If present, it contains the Directory Certificate for the PAC's public key, signed by a CA. Selecting and Extracting Privileges and Controls. At the initiator end, Privilege Attributes and the controls over the PAC's use that appear in the default PAC are chosen on the basis of the user's identity and the role name PAC Protection The PAC can be implemented to support a variety of different kinds of controls over where and when it should be acceptable and who can make use of it. The protection method check is passed by a PAC if all of the method fields in any one of the method groups is passed. In SESAME there are three kinds of protection method, i.e. three possible kinds of control over the use of a PAC: Original owner control.the protection method is known as the PPID Protection method. This method allows the PAC to be used securely from the original owner's workstation at more than one target. Unless delegation is separately permitted, none of the potential receiving targets can pretend to be its owner or act as delegate for its owner. PPID stands for "Primary Principal's Identifier" Delegation control (the CV/PV Method). The CV/PV protection method allows a PAC to be used by proxy, i.e. passed from the initiator to a delegate and then from delegate to delegate or final target. Each delegate then has the capability of issuing new actions to the applications for which the PAC is valid. Delegate/target restrictions. A SESAME PAC may contain one or more target or delegate- target application or "Trust Group" names specifying which targets or delegate-targets the PAC is valid for. A Trust Group name is simply the name of a group of applications, defined by the security administrator, that mutually trust each other not to spoof each others' identities Conclusion Page 96 of 173

104 SESAME consists of a comprehensive set of standards, protocols and services that is specifically aimed at SSSO. It is designed to be secure and flexible, supporting entrenched technologies like Kerberos, but also embracing GSS-API and public- key encryption. SESAME will have a significant influence on the future development of Secure Single Sign-on products. Page 97 of 173

105 Chapter 6 6. Overview of SSO Products Available 6.1 Introduction In this chapter various SSO products that are available on the market today are discussed. The first section consists of a listing of products available, grouped according to the type or classification of the product. The tables were compiled by using information from the European Security Forum's Position Paper on Single Sign-on an basis (Stanley,1996). Several products that were not reflected in this list, were added by the author. The sections following the tables, discuss some of these products in more detail. 6.2 Synchronization Products Vendor Product Name Comments C & K Software (CKS) NC-Syncom ( backbone for CKS's Secured Single Sign-on) Provides single sign-on across distributed IBM Enterprise System environments COM & DIA LLC DiaLOCK Boot Network For PC's on Novell Netware LANs Computer Associates Unicenter Primarily a distributed system management tool but has security functionality Fisher International Watchdog PC-based netwoks Systems Proginet SecurPass Provides password synchronization between MVS,AS/400 and Microsoft SNA Server 3.0 Page 98 of 173

106 6.3 Scripting Products Vendor Product Name Comments Digital Equipment Jabberwocky Corporation Fifth Generation Systems SAFE (Secure Accesss For PC-based Networks Facility for the Enterprise) IBM Network Co-ordinator Manor Park Systems MPS - Single Sign-on Mergent DACS/SSO PC - based PC Security Limited Stoplock (SSO) PC - based Portcullis Computer Guardian Angel PC - based Security Limited Racal Airtech PC - Guard (SSO) PC - based Security Dynamics ACE Works with SecurlD Sterling Software Solve:Access Unisys InfoConnect/ Single Server based scripting Sign-On Uu-Maco Safeguard Systems Safeguard Proffessional for OS/2 6.4 Trusted Authentication Server Products Vendor Product Name Comments Blockade Systems Corp. B-SAFE (Blockade Supports MVS RACF via Security Arhitecture For RACROUTE facility. SSO the Enterprise) integration with Windows NT. Supports tokens from Security Dynamics, Digital Pathways, CRYPTOCARD. (Goldberg,1996) th Dimension Software Control SA Kereberos based Bull ISM/SS (Integrated System Management/ Incorporates strong system management tools Security Services) C 8 K Software (CKS) MyNet Launched early '96. Authentication Server recommended to be mainframe based (discussed in detail below) Cybersafe Corp (formerly Open Security Computing Kerberos Supports GSS-API and Security Dynamics SecurlD card Group) Cygnus Support Kerberos Data General DCE Digital Equipment Corporation DECathena, DCE Page 99 of 173

107 _Single Sign-on in Heterogeneous Computer Environments Dynasoft (Dynamic BoKS, AVI-BoKS Software AB) Hewlett Packard DCE Smart card based solution for distributed Pcs and UNIX systems. Security administration software features dynamic credentials and runs on one or more UNIX hosts IBM Secure Single Sign-on DCE-based Microsoft DCE Millenium Computer Corporation of Pittford, New York. FirstStep(TM) It provides Single Sign-on, User administration and Software Licensing functionality. (FirstStep,1996) Novell NetWare 4 Proprietary solution uses NetWare 4 servers and client software OpenVision Technologies OpenV*Secure Kerberos 5 based OPEN HORIZON, Inc. Connection DCE based, supports Kerberos, CORBA and is also supported by IBM. Provides Web Browser support SCO DCE SESAME consortium ICL, Bull, Siemens-Nixdorf) SESAME - a research project supported by the Eurpean Commission See chapter 5 for detail discusion Siemens-Nixdorf DCE, Sign On SESAME based Silicon Graphics DCE Sun Microsystems DCE Transarc's product, resold by Sun Transarc DCE Also available from Sun 6.5 Hybrid Products Vendor Product Name Comments Axent Technologies Enterprise SignOn (ESC): Single sign-on module of Axent's Omniguard suite Secure authentication server (centralised or distributed) supports sychronization and scripting. Supports or will support Pcs, LANs,UNIX, Windows, VMS and MVS platforms, interfaces to RACF, ACF2 and TopSectret: plus DCE and Kerberos Bellcore One-Pass For IMB MVS environments Century Analysis Inc. CAI-Net Supports Open Standards, Kerberos, Scripting. UNIX and WindoWs NT based. (Century Analysis, 1996) Eberhard Klemens Co E-NSI Page 100 of 173

108 6.5.5 Enigma Logic Inc. SafeWord IBM NetSP Offers alternative sign-on mechanisms including scripting. It is now a 'stabilised product which means no further development ICL AccessManager 300 Offers alternative sign-on mechanisms including scripting MEMCO Software SeOS (Security for Uses Kerberos tickets Open Systems) Microsoft Corp. SNA Server V3.0 The foundation of this solution is the unified sign-on feature of Windows NT Server which provides single sign-on and interfaces to the Windows NT domain., (Microsoft,1996) Zergo ZSA - Supports scripting and DCE Page 101 of 173

109 6.6 Microsoft NT/HOST Security Integration Introduction On May 24, 1996, Microsoft Corporation and Proginet Corporation announced new products to provide a comprehensive solution that allows for single sign-on and centralized security password control across mainframes, AS/400 and Windows NT Server-based LAN environments within the enterprise. This integrated password synchronization and single sign-on solution covers the primary IBM mainframe operating system, OS/390 (Previously known as MVS), the AS/400 operating system (05/400) and all desktop operating systems that are integrated with windows NT Server Security. These products are listed as 6.2.5, and in the list of products above Platforms Supported Clients Servers Windows NT Workstation OS/390 Windows 95 MVS/ESA V4R2.0 Windows for Workgroups AS/400 (OS/400) Windows 3.x VTAM V3R4 MS-DOS Mainframe Security Packages: Macintosh IBM RACF V1 R9 OS/2 CA-Top Secret V4.3 SNA Server V 3.0 CA-ACF2 - V6.0 (Microsoft,1996) Architecture The product consists of two integrated products: SecurPass from Proginet, which provides password synchronization; SNA Server V3.0, which provides single sign-on and interfaces to the Windows NT domain. The foundation of this solution is the unified sign-on feature of Windows NT Server, which enables desktop users to sign-on only once to gain access to all Windows NT Server Page 102 of 173

110 systems on the network, as authorized by the administrator. After initial sign-on, users are then authorized to access files, printers, databases, messaging systems and other applications running throughout the network on any Windows NT Server. (Microsoft,1996) Secured Single Sign-on The single sign-on capability has been built into the operating system for maximum security and transparent operations. SNA Server provides automated mainframe log-on from the LAN. This capability, combined with SecurPass synchronization and Windows Unified log-on, offer secure, integrated single sign-on for enterprise Windows users. Unlike some other security integration solutions, SecurPass does not introduce new security risks in the form of a proprietary database or a sign-on shield menu. SecurPass get direct access to the encrypted NT domain security information which it synchronizes with the host system using the secure communications services of Microsoft SNA Server. SecurPass on Windows NT centralizes mainframe password synchronization for Windows, DOS, MAC and OS/2. The product also provides password synchronization with AS/400 and popular mainframe security systems. This feature makes it possible to have one password for LAN and host access. The single sign-on feature automatically logs the user into the host security system when the user starts a 3270 or 5250 emulation session. For APPC applications, such as DB2 database access from a desktop application, this feature provides the host user name and password as the appropriate connection security parameters. The user's password changes are kept in sync regardless in which environment, the host or the Windows NT Server, the change is initiated Data Encryption This feature provides encryption of all data between the SNA Server and the client, using the industry-standard RSA RC4 data encryption standard. Data encryption is also supported in the distributed deployment of SNA Open Gateway Architecture (SOGA), allowing for secure SNA-server-to-SNA-server communications across the Internet, intranet and other WANs. This feature can provide for end-to-end encryption of all host communications without placing any additional CPU load on the host Security administration SNA Explorer is the name of the new graphical console for all functions in SNA Server. This tool, consistent with the look of the Windows 95 Explorer, is the single point of control for configuring and managing all SNA Servers, host connections, sessions, users, Page 103 of 173

111 security, auditing and other functions in the same domain. SNA Explorer integrates the administration of SNA Server, TN3270 Service, TN5250 Service, SNA Print Service, Shared Folders Service, and Host Security into a single interface. Administrators can centrally and remotely manage all SNA Server computers in their enterprise. Although passwords are kept in sync, the user-ids don't have to be identical between the two systems. This feature can be enabled on a user-by-user basis, allowing flexible security administration. An additional tool is provided to end-users to initialize and update their own password information. This tool allows for rolling out the product to the enterprise without requiring the administrator to configure all users at once. This solution also provides a mechanism for self-healing, should password change transactions get lost for any reason between the LAN and host security systems. (Microsoft,1996) Availability The product is entering Beta testing in May The Windows NT Server component of the solution will be included as part of the next version of Microsoft SNA Server, scheduled to ship during the second half of SecurPass, the host component required for the password sychronization with RACF, CA-Top Secret and CA-AFC2 host security systems will be sold by ProginetTM Corp., and will be available with the next version of SNA Server Conclusion The Microsoft NT/HOST Security Integration product is essentially a synchronization SSO solution (Proginet), with added administrative and confidentiality functionality (SNA Server 3.0). The Microsoft NT platform's unified security mechanism is used as a 'trusted authentication server to provide a secured sign-on. It can thus be viewed as a Hybrid solution. Page 104 of 173

112 6.7 CA-Unicenter/SSO Introduction CA-Unicenter/SSO, listed as in the table of products above, is a new technology of CA-Unicenter/The Next Generation that provides Microsoft Windows-based end users with secure single sign-on and easy point -and -click access to any application accessible from their Windows PC, including UNIX, Windows and Mainframe-based applications. A fully integrated CA-Unicenter feature, SSO leverages all of the authentication, advanced asset access, and auditability features of CA-Unicenter security. SSO's design for operating hand-in-hand with CA- Unicenter eliminates the need to maintain a separate user registry, multiple security environments, reports, or audit trails. Access to specific managed sessions and/or applications is controlled by the central SSO server, simplifying administration, and offering added security by never storing passwords or security policies on user workstations. All access is secured through CA-Unicenter Standard Security Facility (SSF) controls which enable administrators to deploy set-andforget policies to control which applications may be requested by end users. (SSF is a user authentication and asset access verification API supported across all CA security solutions on all platforms.) ( Computer Associates,1996) Platforms Supported Clients Servers Microsoft Windows 3.1 or CA-Unicenter release 1.1 (genlevel 9510 or above later) or above running on: TCP/IP capability Hewlett-Packard HP-UX 9.x or above (through winsock.dll) IBM AIX or above Microsoft NT Workstation Sun Solaris (SPARC) or above (Planned) CA-OpenIngres version 1.1 Resource Requirements X-terminal for the Unicenter GUI 1 MB additional on hard Resource Requirements drive 25 MB additional disk space ( Computer Associates,1996) Page 105 of 173

113 6.7.3 Architecture CA-Unicenter/SSO utilizes a manager/agent architecture to enable automated application access. The PC-resident agent is identical for each end-user workstation since it does not store any sign-on related information or policies. The SSO Server, on the other hand, contains all of the information regarding the different sessions or applications managed by CA-Unicenter/SSO, and also stores any specialized configuration or user data to accomplish the single sign-on goal. The basic philosophy of CA-Unicenter/SSO is to utilize a trusted UNIX server exclusively for the management of sign-on activity. This ensures that all security related information is securely stored, and greatly simplifies the definition and ongoing management of Single Sign-On policies and users. Ca-Unicenter Single Sign-On extends the CA-Unicenter solution set with the ability to automate and securely manage end-user connection to multiple networked servers and applications. SSO can also be used to automate the launching of applications resident on the users PC. End-user always sign-on via the CA-Unicenter/SSO server, which in turn utilizes the advanced user authentication and password controls of the CA-Unicenter Security function on that server. All auditing and control of user access is therefore managed by CA-Unicenter Security, eliminating any need to maintain additional or separate user registries. Single Sign-On server databases can be replicated using the CA-OpenIngres replication feature enabling the environment to support automated fail-over. The CA-Unicenter/SSO client is configured with a primary server, and, optionally, a list of alternate servers. If the primary server is unavailable to support sign-on for any reason, the SSO client will automatically attempt to connect to each alternate server in succession until it succeeds. Computer Associates,1996) CA-Unicenter Security is used for CA-Unicenter/SSO login validation, and to enable administrators to restrict user access to sessions. All CA-Unicenter/SSO audit and violation information is recorded to the same log as CA-Unicenter security, providing a single view of both host and network access. CA-Unicenter/SSO extends CA-Unicenter Security with a new attribute to the User object, and two new managed objects, Sessions, and Session Groups. Page 106 of 173

114 Session objects are used to define sessions, or applications, that are to have sign-on processing automated on behalf of end-users. Session objects also enable administrators to define different handling of the same application using different Sessions. Session Group objects simplify administration by enabling the CA-Unicenter administrator to group all of the Sessions used by an end-user through CA-Unicenter/SSO into a single object, that is then related to the CA-Unicenter User. Three additional databases are also used: The Session table which is used to define which applications or sessions a user should be offered. The Scripts table which stores the processes that are used to automate the login to a specific session. The User Data table is used to store special, fixed information about a specific user, such as a unique ID that should be used when connecting the user to a session where a different userid is required. SSO can utilize external programs to generate PassTicket or Tokens for login processing, and can extract any special information needed by applications during or after the login process. Passwords are never stored on the user's workstation. Login Scripts are processed via secure conversation between the SSO Manager and Agent, and neither the scripts, or any information used in them are ever written to disk on the Windows workstation. All information flowing between the CA-Unicenter/SSO manager and Single Sign-On Windows agent is encrypted. Optionally the user data in the database can be encrypted. A configurable HeartBeat interval is used to specify how often the SSO manager will reconfirm connection to the SSO Agent. During the heartbeat, the Manager will; Verify that a secure connection still exists between the Manager and Agent Verify that the agent is still responding correctly to secure data exchange. Verify that the correct suite of sessions is being displayed for the user. If, for any reason the Agent does not respond to the Manager's HeartBeat, the Manager will immediately issue a series of messages to the CA-Unicenter Event Manager indicating that the user's session is no longer active, and listing the series of applications that the user has connected to. ( Computer Associates,1996) Page 107 of 173

115 USER CA-Unicenter/SSO Logon Message Flow II GUI Desktop Trusted UNIX Server Mainframe 'VCA-Unicenter Security Database Single Sign- On Sessions Table Figure 6.7.1: CA-Unicenter/SSO Logon Message Flow Access to applications via CA-Unicenter/SSO (Figure 6.7.1) always starts with a single sign-on to an CA-Unicenter/SSO Manager (1.) by the user filling in a userid and password on his local SSO login screen. The CA-Unicenter/SSO agent will then one-way encrypt the password locally, and fully encrypt the entire message and send it to the Manager. The SSO Manager receives the message from the CA-Unicenter/SSO agent and interfaces with CA-Unicenter Security to validate the login request (2.). If the userid and password are correct, CA-Unicenter security returns to the CA- Unicenter/SSO manager confirmation the login is valid (3.) along with the name of the user's Default Session Group. The CA-Unicenter/SSO Manager sends to the SSO Agent the contents of a new program group that the SSO Agent builds on the user's desktop. (4.) This new program group Page 108 of 173

116 appears on the user's desktop and shows the user which applications/sessions he or she can connect to under SSO control. At this point the user has been authenticated via CA- Unicenter/SSO, and the appropriate Heartbeat between the Manager and Agent has been established to verify the connection. CA-Unicenter/SSO will not take any further action at this time until the user requests connection to a controlled session. Agent CA-Unicenter/SSO Application Message Flow GUI Desktop (f) (I) APPLICATION (b) T usted UNIX Server SSO Manager b) CA Unicenter/Single Sign-On Mainframe Single Sign- On User Data Table Ticket, Token & Special Data Routines (c) ,..., N... _ , Single Sign- CA-Unicenter Single Sign- On Scripts Security On Sessions Table Database Table... _...,... _...-, Figure 6.7.2: Ca-Unicenter/SSO Application Message Flow The end user requests connection to an application by double-clicking on one of the icons in the CA-Unicenter/SSO program group (Figure 6.7.2). The following occurs: A secure connection is established from the SSO agent to the SSO Manager. (a) The Manager is sent a request to "start' the login to this application. (b) Page 109 of 173

117 The SSO manager will first issue a SSF check to the CA-Unicenter Security (c) to verify that the user is in fact still authorized to this session. If not, the connection is refused. If authorized, the CA-Unicenter/SSO manager will retrieve the name of the CA- Unicenter/SSO script associated with the selected session from the Scripts Table (d). This script will then be used to drive the connection to the session through communication between the CA-Unicenter/SSO Manager and Agent. Scripts may contain variables that may be: Platform-specific userids and passwords; Tokens or tickets (e) to be used in place of passwords; any user-specific data needed to launch the application (f), or take the user to a specific panel or place within the application as desired. The required variables for the CA-Unicenter/SSO script will be obtained from the User Data table (b), invoking an external program such as a Ticket generator, or prompting the end User for variables in the User Data Table if not already filed in. Once all the required variables have been satisfied, the CA-Unicenter/SSO Manager begins a secure conversation with the CA-Unicenter/SSO Agent and performs the operations defined in the script. The end- user can start as many sessions as desired. An audit record will be sent to the CA-Unicenter Event Manger to record each connection. Computer Associates,1996) Fail-over and Recovery The SSO Agent contains extensive error-recovery and reconnect logic to provide maximum resilience to slow or erratic networks. In addition to the error recovery logic, the SSO Agent can automatically fail-over to one or more alternate Managers if the primary is unavailable. This fail-over is automatic, and the end user will perceive it only as a longerthan-usual connection to the SSO environment. Managers can be replicated utilizing the full two-phase commit replication logic of the CA-. OpenIngres database that CA-Unicenter/SSO is supplied with. By replicating both the SSO database, and the CA-Unicenter Security database, multiple fail-over environments can be easily established to ensure that users will always have a Manager available when they need to login. Page 110 of 173

118 6.7.5 Availability CA-Unicenter/SSO is currently available. Integration with the Microsoft Windows NT logon is expected by the end of Conclusion CA-Unicenter/SSO is classified as a scripting solution by the European Security Forum (Stanley,1996), but contains elements of a trusted authentication server which enhances the level of security. Page 111 of 173

119 6.8 CKS MyNet Introduction The core of CKS MyNet ( in the list of products) is its Authentication Server, providing a central directory where all logons to servers are authenticated against the user profile and automatically audited. It is recommended by CKS to use the most trusted server as the MyNet authentication server. This is likely to be the mainframe, where access control is done via IBM RACF, CA-ACF2 or CA-TopSecret. MyNet provides users with a number of SSO functions which give them the ability to reach data and applications on multiple heterogeneous platforms with a single authenticated logon, via a simple and consistent Graphical User Interface (GUI) on their workstation. Applications are presented to users, on their workstation, as a customizable point and click menu, known as the AppDesk, built from a central administration database. When new systems are rolled out, the administrator simply adds the appropriate applications to the central menu and specifies the users or group of users to which the applications apply. (CKS,1996) Platforms Supported Clients Client/Servers Servers Microsoft Windows 3.x Novell Netware 3.1x IBM AS/400 DOS Novell Netware 4.1x IBM MVS IBM OS/2 IBM LAN Server(3,4 and HP/UX Microsoft NT Workstation WARP Server IBM AIX Microsoft NT Server (3.5.1) DEC VMS IBM VM Sun Solaris (CKS,1996) Agent based Architecture Page 112 of 173

120 MyNet is an agent -based system. An attempt by a user to logon to the Network Operating System (NOS) activates the Primary Agent which resides on the NOS. Secondary Agents reside either on mid-range or mainframe systems and provide synchronization facilities. The Primary Agent transmits the logon information to the Authentication Server, which determines and checks the information the user needs to provide for that environment. When the user has been successfully authenticated, the user is logged on to the NOS. When the user attempts to access an application anywhere on the network, the authentication Server provides the required credentials to allow application entry Single Sign-on Once users have successfully logged on, they can use the MyNet SSO functions, one of which is the MyNet AppDesk. The AppDesk displays a list of all application groups, known as rules, to which the user has access. Each rule consists of one or more applications, which are displayed as buttons when the user selects the appropriate Rule. To access an application, the user clicks on the appropriate application button; the user will not be asked for a user ID and password, because the user has already been successfully authenticated at logon. The process of connecting to the application is transparent to the user and the application will be presented on the desktop ( unless corporate security standards dictate that the chosen application requires secondary authentication, in which case the application will be presented when the user has provided the appropriate secondary authentication data). (CKS,1996) Scripts For many applications, MyNet's architectural design minimizes the need for scripts. MyNet can automatically connect a user to applications that require a user ID and Password, and accept these credentials on the command line. Client/ Server applications can also make use of the MyNet API to ensure that a user has been successfully authenticated. Where global scripts are required, this is managed by MyNet's Automated Global Scripting facility. The administrator can create and modify scripts. The scripts are stored on the Authentication Server. End-users are not able to create or modify scripts. MyNet scripts contain only symbolic references to the user ID and password provided at logon; the user ID and password are therefore not stored in any MyNet script. Two types of script are supported: Page 113 of 173

121 GUI scripts HLLAPI scripts. GUI scripts are scripts containing a series of CKS script language statements, which, when replayed, are interpreted to the underlying messages that are processed by both Windows and OS/2 Presentation Manager. HLLAPI scripts are scripts containing commands which are converted to IBM's High Level Language Application Program Interface (HLLAPI) calls, used for manipulating 3270 Presentation Spaces. (CKS,1996) Administration The administrative functions are split between the LAN and the Authentication Server. Administration functions can be centralized or distributed, as required. On the LAN, Administration functions are required to manage the following areas: users AppDesk menus scripts access rights for the administrators configuration data The distinction between an administrator and a user is in the user's profile definition. Ordinary end-user can be authorized to customize their own AppDesks but will not be able to incorporate new applications into the AppDesk or change the script definitions for those which are already defined. In addition, access control lists can be used to limit a specific administrator's authority to certain applications and/or users. (CKS,1996) The Authentication Server has a central database containing access control information for the users and workstations on the network. Records containing sensitive data in the Authentication Server database are protected by a cryptographic checksum, to prevent unauthorized modification of stored information. The Authentication Server (AS) also informs other agents of events such as password changes, revoke/resume commands or user profile administration: those agents (e.g. running on a UNIX machine) update the local account data with the changes propagated from the Authentication Server. This ensures that when a user attempts to access an application running on one of those agents, the password that the user provided at logon can subsequently be used to access the application, knowing that it will be accepted. In addition, the AS provides all other services that may be required for authentication, for example secondary authentication, Page 114 of 173

122 real-time synchronization of password changes and revoke/resume commands to all MyNet integrated platforms and the generation of RACF Pass Tickets for secure single sign-on. Both DCE and Kerberos applications are supported Gateways MyNet gateways are provided as a means of communication between the agents and the Authentication Server, where direct communication is not possible, i.e. the communication protocols used are different. MyNet gateways receive data from multiple sources using different communications protocols and route that data to the Authentication Server using the APPC protocol. MyNet Gateways support the following environments: Microsoft SNA Server Novell Netware for SAA IBM Communication Manager/2 (CM/2) IBM SNA Server/6000 IBM SNA Services/6000 (CKS,1996) MyNet Fallback MyNet has been designed so there is no single point of failure. To enable this design, MyNet can be configured to work in fallback mode. In Fallback mode, MyNet uses information provided at the last successful logon. If the Authentication server is not available and a user has Fallback enabled, the user logs on as normal, providing his/her enterprise user ID and password. The Primary Agent checks the user ID and password against the last successful logon which used the Authentication Server. If these match, the user will be allowed to logon. Fallback is therefore a restricted security check on user ID and password only Token Support MyNet supports several different personal devices or tokens, all of which provide a code to be input when additional authentication is required, either at logon or when requested by an API call to protect sensitive transactions or applications. Page 115 of 173

123 Single Sign-on in Heterogeneous Computer Environments Information about these personal devices, including the ID's to Which they are assigned, is held in the Authentication Server Database. If required, the token assignment information can be held in an external security database Audit MyNet provides a central logging facility on the AS. All administration and access function messages are written to MyNet logs and may optionally be written to the system console for on-line browsing. Fast retrieval of potentially important messages, such as logon failures is therefore provided. Actions can also be selectively audited depending on frequency within a given period. A user can be revoked or resumed immediately across all platforms with one command across the entire network. Similarly, a user can be deleted from the entire network. (CKS,1996) CKS MyNet Message Flow 8 GUI Desktop 7 "vg APPLICATION I CJ 4 / re NC Server 3. Authentication Server (AS) Figure : CKS MyNet Message Flow 2. Page 116 of 173

124 When a user requests logon (figure 6.8.1) to their local server (1), the local server immediately applies to the Authentication Server (AS) for validation of the user profile residing on CKS MyNet or on IBM RACF, CA-ACF2 or CA-TopSecret databases (2). At this point, the AS may challenge the user for a higher level of authentication, such as a token (3). If the user is validated, the AS sends the user's current authorized applications list to the user's server, with confirmation of the access validation (4). If the list hasn't changed since the user's last logon, it will already reside on the local server, ensuring fast performance for re-logons and back-up availability in emergencies. The user's list of authorized applications is then displayed in an icon-based graphical form on the desktop (5). To access an application, the user clicks on the appropriate icon (6). The rest of the process is transparent to the user. When the application requests the user's credentials (7), the local server intercepts the request (8) and responds with a valid credential, acceptable to the application. Depending on the level of security in force, the credential may be an encrypted userid and password, or something more specific like a perishable password or ticket (9) Availability The initial MyNet offering is directed at a distributed environment; however, it requires IBM's MVS implementation to serve as the primary authentication server. A future release that will enable the authentication server to be supported on a distributed platform such as Windows NT server or Unix is being analyzed by the vendor. (CKS,1996) Conclusion CKS MyNet is classified as a trusted authentication server product (Stanley,1996), using IBM's RACF or CA's ACF2 security databases as the authentication server. Page 117 of 173

125 6.9 ICL AccessManager Introduction AccessManager (6.5.7 in the table of products) is a ITSEC E2 Certificated product which provides for Single Sign-on, network security and user management. In addition to these basic security functions, AccessManager has also been designed to accommodate existing and emerging products and technologies which conform to the European Computer Manufacturers Association (ECMA) security architecture. This architecture, defined in ECMA TR/46 and associated standards, provides a security framework in a network of open components from ICL and other vendors. These standards are currently being proved under the European Union funded SESAME project. (ICL,1996) Platforms Supported Clients Servers HP-UX ICL's Teamserver and Superserver Sun SPARCstation DRS Server range running UNIX SVR4 Microsoft Windows 3.x Sun Solaris VT220 terminals Sun SPARCServer Motif HP/UX OpenLook IBM AIX DOS UnixWare based Server OS/2 [19] Novell Netware 4.1x Dial-up PC's IBM MVS Windows95 Security Features Supported Windows NT Client & Server IBM RACF ACF2 TopSecret DCE Kerberos SDTI,s SecurelD card PCSL StopLock RACF Passticket Page 118 of 173

126 6.9.3 General Description Single sign-on is currently provided through scripting. From terminals, this is through AccessManager's own Task Scripting Language. From the Microsoft Program Manager, this is via use of PC terminal emulators which have a suitable scripting facility, or, where supported by the applications, by the use of DOS commands. Users must authenticate themselves to use AccessManager via a username and role. A password or magnetic badge may also be demanded. Third party security applications and authentication devices (such as smart cards) may be integrated via an AccessManager API. Passwords are held encrypted on the AccessManager server and appropriate validation such as password lifetime, length, or the minimum number of alpha and numeric characters may be specified. Usernames and passwords for remote services can also be held encrypted. AccessManager conforms to the European Computer Manufacturers Association (ECMA) security architecture. More secure access to specific services will be provided by a technique which manages the links, known as associations, between users and applications. These associations are formed between users and applications within a secure framework each time a user accesses the application. The range of techniques known as Association Management are currently being transferred from SESAME. The use of Association Management avoids the need for additional connectivity programming by making use of the GSS-API standards. The roles, menus, and applications available to end users can all be defined centrally by the AccessManager Central administrator, as can the security configuration for each Local Server, Sun workstation and PC. This information is then propagated to the local servers. AccessManager also provides hooks for the administration of non AccessManager users. ICL Accessmanager supports Windows 95, Windows NT Client and NT Server, as well as IBM's RACF Passtickets Availability AccessManager software for Windows 95 client and Windows NT servers, as well as NT clients are available as from the end of June Page 119 of 173

127 6.9.5 Conclusion Although earlier versions of AccessManager have different capabilities, AccessManager 300 is classified as a Hybrid Product (Stanley,1996). Page 120 of 173

128 6.10 FirstStep Introduction FirstStep(TM) ( in the list of products) is a product marketed by Millenium Computer Corporation of Pittford, New York. It provides Single Sign-on, User administration and Software Licensing functionality. (FirstStep,1996) Platforms Supported Clients Security/ Servers Authentication Servers Windows 3.x Windows NT Server OS/390 (MVS) Macintosh Sys 7 UNIX UNISYS Unix DEC VMS HP DataGeneral minicomputers Planned: Kerberos DCE (FirstStep,1996) General Description FirstStep is based on a three tier architecture, namely: client, security server and host. The FirstStep Security Server provides the core of the single sign-on capability. It consists of one or more Unix systems running the FirstStep server software, with the FirstStep Administrator and Software License Accountant add-on modules. The FirstStep server forms a common interface for the client software components. The FirstStep server operates by using a database of 'user profiles' and publishing Remote Procedure Call (RPC) services. The users belong to groups, or role groupings, to facilitate administration where groups of users may have similar or identical desired Page 121 of 173

129 capabilities. The Administration Module is used to set up the system and the user profile database. Under each user, there is an associated list of host systems each is authorized to access, and if necessary, an encrypted userld and password associated with that access. Using this database of information, the server can log a user automatically to any of the other hosts they are authorized to access while maintaining an access audit trial. For each such host connection, there is also a database record which tells the system which client workstation software program to run. A end user enters a UserlD and Password at any FirstStep client workstation. The client software makes an RPC to the server. The server accepts or rejects the sign-on. If the password is rejected, the user is notified by an error message and may try again. The security server controls the number of attempts a user can make to access the system. If the sign-on request is successful, the server returns a 'profile record' to the client front end software. Portions of this profile record are encrypted as appropriate to the data content. All UserlDs and passwords for other systems are encrypted at the security server, transmitted in their encrypted form over the network, and are saved in memory, still encrypted, on the client workstation. The FirstStep client software uses the profile record internally to make requests to connect to other hosts on the network. The security server makes RPC services available to all of the client stations. Then the package is also used once a client station initiates requests to the server. In this way, the database implementation on the security server is transparent to the client workstation software. Also the physical implementation in terms of one or more security servers is also hidden from the client software. (FirstStep, 1996) Features of FirstStep GUI. FirstStep provides a graphical, user-specific menu of push buttons that provides access to the applications and platforms the user is authorized to use Single Sign-on. The user uses a single UserlD and Password. After the system authenticates the user, it automatically and transparently logs the desktop user onto any system he or she chooses and is authorized to access. Page 122 of 173

130 Secure Remote login. When a user logs in from a remote location, the UserlD, and passwords are sent, and the user application profile is received, in the DES encryption format Time-based screen lockout. The screen keyboard locking function will be initiated automatically based on a preset amount of idle time, or on demand by pressing a button Encryption on desktop level. Users can access encrypted data from a desktop or remote location and send encrypted files to the server and other users. DES is supported Token card support. FirstStep allows the use of token cards in authenticating a client user Secure messaging. All permanent and temporary FirstStep server files are Data Encryption Standard (DES) encrypted. Ultimately, FirstStep will incorporate security and authentication services provided by the Distributed Computing Environment (DCE) and Kerberos. (FirstStep, 1996) Conclusion FirstStep can be classified as a Trusted Authentication Server Product. Page 123 of 173

131 _Single Sign-on in Heterogeneous Computer Environments 6.11 IBM Secure Single Sign-on Introduction IBM Corporation ( in the list of products) announced its intention to provide a Single Sign-on product on May 20, Passwords for the product will be controlled by the Kerberos authentication mechanism used in the Open Group's Distributed Computing Environment.(IBM,1996) Platforms Supported Clients Servers OS/2 Warp Mainframe Security Packages: IBM RACF General Description The IBM Single Sign-on product will be based on the security services provided by OSF DCE. Authentication will be done by the Kerberos authentication mechanism. The majority of the technology needed already exists in IBM products and will be integrated to provide a solution with the following characteristics: Single sign-on is achieved through a three tier client/server model where the burden is minimized for the client. Multiple authentication mechanisms are supported, i.e. passwords, one time randomly generated passwords, RACF Passtickets. Users authenticate themselves only once per working session, using the DCE login mechanism. Where possible, security on the client desktop is integrated with this login. Extended registry attributes, provided by DCE 1.1 compliant security servers, will be used to store information on user access to non-dce resources. Desktops must have DCE 1.0 compliant support, or better. Page 124 of 173

132 Users will be provided access to an authorized list of resources based on their profile groups, roles, etc.) maintained in the DCE cell registry. This may include DCE applications, MVS 3270 applications, LanServers, Novell servers, and GSSAPI applications. An option to extend single sign-on to ODBC is planned also. Users may roam and still receive access to their authorized resources. Multiple methods for signing a user on to authorized resources are supported, such as automatically or explicitly by double clicking on an icon. Administration is available via the DCE cell capabilities. These may be extended via IBM's Distributed Security Manager products to centrally administer distributed security profiles. IBM is developing the framework for single sign-on by blending key technology from NetSP Secured Logon Coordinator (NetSP SLC) with the rich security services offered by DCE. As OSF/DCE specifications are provided to foster non-dce resources ability to use DCE services, IBM will integrate the security services to ensure compliance with the standard IBM Directory and Security Server (DSS)for OS/2 Warp This product delivers an OS/2 Warp implementation of the Open Software Foundation (OSF) distributed Computing Environment (DCE) version 1.1. It provides distributed directory, security and time services as well as a remote procedure call interface for distributed application development. This allows OS/2 Warp Server clients, on any supported platform, to seamlessly access resources across domain boundaries using a single identification and password. Administrators no longer need to maintain a separate definition for each user in every domain that they must access. (McKelly,1996) DSS Components The following components are all part of the DSS package: DCE Directory Server. This is a standard OSF DCE 1.1 cell directory server (CDS). CDS enables clients and DCE application programs to locate objects in a DCE or DSS network. (McKelly,1996) DCE Security Server. DCE uses a Kerberos third-party security service for authenticating both application clients and application servers. In addition, DCE access control lists (ACLs) allow the owners of resources to determine who is allowed Page 125 of 173

133 to access the resources. DSS provides a security server with full OSF DCE 1.1 support, including the use of extended registry attributes, to make it possible to integrate existing applications with DCE. (McKelly,1996) DCE Client. The DCE client provides the remote procedure call (RPC) interface that enables distributed application support on heterogeneous platforms. Both application clients and application servers run on the DCE client. The DCE client also includes a graphical user interface (GUI), which can be used to administer any DCE component in the system. (McKelly,1996) DFS Client. This is an OSF DCE 1.1- compatible implementation of the DCE Distributed File System client. (McKelly,1996) DSS Client. This component contains an OS/2 Warp Server OS/2 client and a Directory and Security Server slim DCE client, as well as the function to allow them to work together. The DSS client also contains an administration GUI. This GUI is a superset of the DCE administration GUI, and it can be used to administer both the DCE and OS/2 LAN Server components of Directory and Security Server. (McKelly,1996) DSS Cell. OS/2 LAN Server domains are combined to form a single DSS cell. Clients are defined only once in the DSS cell registry and have seamless access to all resources for which they are authorized within the cell. The cell registry contains the user definitions and passwords for ever user in the cell. Users have only one password to change and administrators have only one definition to maintain for each user, regardless of the number of OS/2 LAN Server domains that are combined in the cell. (McKelly,1996) Relationship between the Directory and Security Servers. The directory servers use the security server's authentication service to prove to each other that they are indeed valid servers. They use the security service's Access Control List (ACL) facility to restrict directory server administration to only those userids that have been stamped using the facilities provided by the time server. The DSS domain controller uses the directory server to locate objects, both in the home cell and in other cells. It also stores the DSS resource domain information in the directory server's database. Page 126 of 173

134 The time server registers itself as an object in the directory database and uses the directory server to find other time servers in the network. It uses the security service for mutual authentication. (McKelly,1996) The security server registers itself with the directory server as an object in the directory database. The security service uses the time synchronized by the time service to ensure that passwords and the service tickets that allow clients to use Directory and Security Server services are properly time stamped and voided when they expire. The DSS domain controller uses the security server to authenticate unchanged OS/2 LAN Server clients and servers. In addition, the DSS domain controller uses the security server to obtain security information for propagation to unchanged additional servers. The DSS client uses the security server for authentication and to obtain permission to use Directory and Security Server services. (McKelly,1996) Services The basic role of the security server is to allow DSS clients and servers to prove their identity. The security server includes the following services: Registry Service. It manages the cell registry database, which holds all of the user definitions for the entire cell. Authentication Service. This service allows a DSS user to positively identify themselves to the network. Privilege Service. This service manages the privilege attributes associated with users and groups. It is these privileges that determine which resources a user can access. Access Control List Facility. The ACL, in combination with the privilege service, ensures that resource owners can grant privileges to only those users and groups that should have access to certain resources. Login Facility. This facility authenticates a user to the network, through DCE by means of a single, integrated login. (McKelly,1996) Availability IBM confirmed that Microsoft Corp. Windows NT file and print servers may not be supported in the first release. Windows 3.1 clients and IBM's AS/400 and OpenVMS Page 127 of 173

135 systems Will also not be supported. (Computerworld, 1996) IBM anticipates delivering an integrated product solution by the end of (IBM,1996) Page 128 of 173

136 6.12 OPEN HORIZON's Connection Introduction Open Horizon has developed a family of products called Connection ( in the list of products) which allow users to transparently and securely access heterogeneous applications and databases. The solution combines a standard network authentication model (the DCE Security Service based on Kerberos), and naming services (the DCE Cell Directory Service), together with heterogeneous databases and application services. Connection adheres to the -Switzerland Approach" by providing a consistent standardsbased architecture for all major databases and application servers. (Open Horizon, 1996) Platforms Supported Clients Servers MS Windows 3.x HP/UX 9.0+ MS Windows NT SunSoft Solaris 2.4+ Future: AT&T GIS MP-RAS OS/2 Warp Digital Open VMS MS Windows 95 IBM AIX 3.2 Apple Macintosh Future: IBM MVS 5.1 SCO SVR4 Ahmdahl UTS 4 Sequent Ptx Digital UNIX (Open Horizon, 1996) General Description Connection, OPEN HORIZON's flagship product, is composed of two primary components: Connection Client and Connection Server. Connection Client resides on every workstation, and both Connection Client and Connection Server reside on every server that participates in the distributed environment. Additionally, a Connection Server library resides on every server platform that will participate in the environment. Page 129 of 173

137 Client Server Server Figure : Connection Client and Server relationships (Open Horizon, 1996) OPEN HORIZON'S design goal is to provide a single client-resident component that acts as the interface between virtually any application (PowerBuilder, Visual Basic, PeopleSoft, Excel, Java, etc.) with virtually any service available in the enterprise (databases, security services, directory services, application services, and management services). The various product modules embrace existing and new applications in a 2-tier and 3-tier environment by exposing the standard database interfaces used in virtually all client/server applications and development tools. Leading packaged applications, such as PeopleSoft, Scopus. and Clarify, or off-the-shelf tools and applications such as PowerBuilder, Visual Basic, Delphi, and Java immediately benefit from Connection. The Connection middleware products can be used for secure Internet and Intranet communications over all major networks Security Features Client/server solutions implemented with Connection adhere to the strict standards set forth by the toughest auditing groups. These requirements include that: No password is ever sent across the network - even if it is encrypted. No password is ever stored. Authorized users may only impact critical data through authorized applications. Any client/server implementation must allow end to end auditability. (Open Horizon, 1996) Page 130 of 173

138 Communications Connection Client and Connection Server components are the "end-points." For communications transport, Connection is able to embrace several different RPC implementations. Since the secure single sign-on solution requires a secure RPC transport, the DCE RPC and DCE's POSIX threads implementation are required to send and receive both data and requests between the client and server end-points. 1. The user attempts to connect to a 'logical' database Connection Client checks for credentials 4. The Connection wet performs the Application Auth ntication Client Connection Client DCE Runtime Server Connection Server DCE Runtime The Connection Server connects to the database and alters the user's password. The Connection Server logs into database with random password. The random password is deleted from memory. DCE RPC & POSIX Threads rc -----N\ ecocuemy \ Service DCE Directory Service ---,/ 2. DCE Directory identifies the physical location of the catabase 3. The Connection Server validates :he users ticket Figure : The logical message flow for a user connecting to a data source (Open Horizon, 1996) Application Program Interfaces The architecture is designed so that an existing application that was previously connected to a database can simply "plug-into" Connection with no changes. This is achieved by providing client-resident libraries that accept standard database APIS (e.g., Microsoft's ODBC, Oracle's 001, and Sybase's CT-Lib). Page 131 of 173

139 Availability Connection will be available by mid (Open Horizon, 1996) Conclusion OPEN HORIZON'S Connection can be classified as a Trusted Authentication Server Product. Due to the adherence to open standards like DCE and Kerberos, as well as the support by a major vendor like IBM, this product may become a very important contender in the SSO product market Conclusion There are many products available on the market today that may be suitable as solutions to provide Single Sign-on to the enterprise environment. There is a strong indication that manufacturers strive towards standardization. Many products thus support open standards. DCE in particular. Other technologies include Kerberos, RACE- PassTickets, SESAME and tokens like SecurlD. As can be deduced from the varied approaches to SSO, variety of platforms supported and mechanisms used, careful selection and evaluation of products are essential, but it is clear that DCE will undoubtably become the de facto standard for SSO in future. Page 132 of 173

140 7. The ideal Single Sign-on Solution 7.1 Introduction When selecting a SSO solution, numerous requirements can be considered. These must include functional requirements as well as other requirements like product maturity. installed base. supplier stability, level of support available, introduction of new vulnerabilities and, obviously, cost. Only functional requirements and the introduction of vulnerabilities are considered in the list below. The list of requirements was compiled from various sources, including the list compiled by the. Georgia RACF User's Group (GARUG, 1995), and added to by the author, from practical experience in assisting with the selection of a SSO solution for a major bank. This list is not exhaustive and some variation could be expected for specific computing environments. For brevity's sake, 'Nice to Have' features have been omitted. Requirements are grouped according to the security services required as identified in chapter 2, namely: Authentication, Authorization/Logical Access Control, Security Management and Administration, Auditing, Cryptographic services, Key management, Integrity, Confidentiality and Availability. Furthermore requirements are ranked as Essential or Recommended and are uniquely identified by a code which indicates the type of security service it provides. 7.2 Authentication Single Automated Logon (AUTH E01). A single automated logon is one of the primary requirements of the product. The product should enable authentication by a single logon to all enterprise resources, by a single userid and password, or tokenibiometric plus password. Re-authentication should only be required if considered necessary for a enhanced level of security Support common Password Rules (AUTH E02). All common password rules should be supported: Use or non-use of passwords Password length rules Password aging rules Password change rules Page 133 of 173

141 Password change intervals Password syntax rules Password expiration warning message Save previous passwords Password uniqueness rules Limited number of logons after a password expires Customer defined rules Support a Standard Primary USERID Format (AUTH E03). All common USERID syntax rules should be defined by the administrator. The product should include features to translate unlike USERIDs from different platforms so that they can be serviced. This enables the product to handle USERIDs from systems that support different USERID syntax that cannot be supported natively Auto Revoke after a number of invalid Attempts (AUTH E04). Users should be revoked from system access after a specified number of invalid attempts. This threshold should be set by the administrator. This ensures that invalid users are prevented from retrying sign-on's indefinitely Capture Point of Origin Information (AUTH E05). The product should be able to capture telephone caller ID or phone number for dial-in access information if needed. This will provide an administrator increased information that can be acted upon manually or via an exit to provide increased security for chosen ports Support Sign -on's from Variety of Sources (AUTH E06). The product should support signons from a variety of sources. LAN/VVAN, workstations, Laptops/Notebooks, Dial-in. and Dumb terminals are included. This ensures that all signon sources are able to provide sign-on access without compromising the level of security Ensure USERID Uniqueness (AUTH E07). The product should ensure that all USERIDs are unique, no two USERIDs can be the same. This prevents two users from having the same USERID Authentication Server should be Portable (AUTH R08). The product should provide for the authentication server to reside on any platform that the product can control. This provides needed portability if there is a need to move the authentication server to another platform for any reason. Page 134 of 173

142 7.2.9 Support Public/Private Key technology (AUTH R09). the product should support asymmetric encryption technologies such as RSA. This be used for strong authentication and non-repudiation services Support Tokens/Biometrics (AUTH R10). The product should support the use of security tokens such as smart cards, challengeresponse tokens and biometrical devices to enable their use on any platform. This enables the administrator to provide for increased security measures where they are needed for access to the systems. 7.3 Access Control and Authorization Differentiated administration Privileges (ACL E01). The product should support administration privileges at differentiated levels, configured to suit the security/ business needs. This enables the product to be administered by several administrators without the administrator's authority overlapping Default Protection unless specified (ACL E02). The product should provide for the protection of all resources and entities as the default, unless the opposite protection for only those resources is specified. The enables each organization to determine the best way to install the product based on their own security needs Ability to support Scripting (ACL E03). The product should support the use of scripting for legacy applications and systems. Due care should be taken not to allow passwords or critical security information to be transmitted or stored in clear text scripts Physical Terminal/Node/Address Control (ACL R04). The product should have the ability to restrict or control access on the basis of a terminal, node, or network address. This ability will enable administrators to manage access control by physical location Single Point of Authorization (ACL R05). All authorizations should be made via a single point, i.e. an authentication server. The product should not need to go to several versions of the product on several platforms to gain the needed access to a resource. This provides not only a single point of administration for the product, but also reduced network security traffic. Page 135 of 173

143 7.3.6 Support Standard Ticket/Certificate Technologies (ACL R06). The product should support standard ticket or certificate technologies such as IBM's RACF Pass Tickets, Kerberos certificates or SESAME Privilege Attribute Certificates (PAC's), ensuring that the product can reside in an environment using ticket / certificate technology to provide security authentication and authorization. (IBM, 1994: SESAME, 1996) Support Masking/ Generics (ACL R07). The product should support security profiles containing generic characters that enable the product to make security decisions based on groups of resources of generic equivalence, as opposed to individual security profiles. This will enable the administrator to provide security profiles over many like-named resources with the minimum amount of administration Allow Delegation Within Power of Authority (ACL R08). The product should allow an administrator to delegate security administration authority to others at the discretion of the administrator within his/her span of authority. An administrator would have the ability to give some of his/her security authority to another administrator for backup purposes. 7.4 Data Integrity/Confidentiality/Availability No Clear-text Passwords (DICA E01). At no time should any password be available on the network or in the security database in clear, human- readable form. The only exception is the use of dumb terminals where the terminal does not support encryption techniques. This will ensure the integrity of the user' passwords in all cases with the exception of dumb terminals. Where dumb terminals have to be used, 'one-time' passwords should be considered, possibly together with challengeresponse tokens Integrity of Security DB(s) (DICA E02). The database used by the product to store security information and parameters should be protected from changes via any source other than the product itself. Generic file edit tools should not be able to view or update the security database Failsoft Ability (DICA E03). The product should have the ability to perform at a degraded degree without access to the security database (e.g. by utilizing a cached role profile stored on a local server) This ability should rely on administrator input on an as needed basis to enable a user to signon, access resources and sign-off. This enables the product to at least work in a Page 136 of 173

144 degraded mode in emergency in such a fashion that security is not compromised. It is also important that the product does allow direct sign-on's to servers under special circumstances where emergency access is needed Inactive User Time -out (DICA R04). All users who are inactive for a set period of time during a session should be timed out and signed off all sessions. This ensures that a user who becomes inactive for whatever reason does not compromise the security of the system by providing an open terminal to a system Commercial Standard Encryption (DICA R05). The encryption used in the product should be standard. That standard is presently DES but could change as new encryption standards are made. This will ensure that the product will be based on a tested, generally accepted encryption base Option for Single or Distributed Security Databases (DICA R06). The product should support the option of having a single security database or several distributed security databases on different platforms. This enables an administrator to use a distributed databases to spread the workload to prevent over-utilization of servers Inactive User Revoke (DICA R07). All users who have not signed on within a set period of time should be revoked. The period should be configurable by the administrator. This will ensure that USERIDs are not valid if not used within a set period of time Optional Application Data Encryption (DICA R08). The product should provide the optional ability to interface to encrypted application data if the encryption techniques are provided. This enables the product to interact with existing application encrypted data Key Management (DICA R09). A Trusted Key Management Center / Certificate Authority is essential when dealing with cryptographic keys. This is especially true if asymmetric encryption is to be used. 7.5 Security Administration Management and Auditing Single point of Administration (SAMA E01). The product should provide for full administration from a single point, if required. The administrator should also have a 'single view' of all the users roles within the enterprise environment. This also enables an administrator to provide support for the product from any one platform device. Page 137 of 173

145 Single Sign-on in Heterogeneous CoMputer Environments Role - profile based (SAMA E02). The product should enable the grouping of like Subjects (users) and Objects into role based profiles, using Discretionary Access Control. These groups / roles should be handled the, same way individual users / resources are handled. This will enable more efficient administration of access authority Full Audit Trail (SAMA E03). All changes, modifications, additions, and deletions to the security database should be logged. This ensures that all security changes are recorded for review at a later time. The audit trail for all systems should be configurable to suit different security requirements and reduce overhead. The logging should include the origin of the logged item or action, the destination, the application involved and the platform involved. This enables the administrator to provide a concise map of all activity on the enterprise. The degree of logging should be controlled by the administrator Single Revoke/Resume for All Platforms (SAMA E04). The product should support a single revoke or resume of a USERID regardless of the platform. This ensures that a user can be revoked or resumed with only one command from one source or platform Ability to Enforce Enterprise Security Rules (SAMA E05). The product should provide the ability to enforce security rules over the entire enterprise regardless of platform. This will ensure the implementation of a single security policy and consistent security over resources on all protected platforms Ability to Trace Access (SAMA E06). The product should enable the administrator to be able to trace access to systems regardless of system or platform Scoping and Decentralization of Control (SAMA E07). The product should be able to support the creation of spans of control so that administrators can be excluded from or included in certain security control areas within the overall security setup. This enables an administrator to decentralize the administration of security functions based on the groups/nodes/domains/enterprises that the decentralized administrator has control over Synchronization Across all Entities (SAMA E08). The product should synchronize security data across all entities and all platforms. This ensures that all security decisions are made with up-to- date security information. Page 138 of 173

146 7.5.9 Real-Time and Batch Update (SAMA E09). All changes should be made on-line /real-time. The ability to batch changes together is also important to enable easy loading or changing of large numbers of security resources or users Customize in Real -time (SAMA E10). The ability to customize or make changes to those features which are customizable without re-initializing the product, is important. This feature will ensure that the product is available for twenty-four, seven day-a-week processing User Defined Fields (SAMA Eli ). The product should have a number of user customizable/ user-defined fields. This enables a user to provide for informational needs that are specific to his/her organization Support Customized Reporting (SAMA E12). The product should have the ability to create customized reports using SQL query or similar reporting tools to produce security setup reports/queries. This feature will enable easy access to security information for administrators Support User Exits/Options (SAMA R13). The product should support the addition of user exits/options that could be attached to the base product at strategically identified points of operation. The points would include: signon, sign-off, resource access check, etc. This enables an administrator or key technical support personnel to add exit/option code to the package to provide for specific security needs above and beyond the scope of the package Customizable Messages (SAMA R14). The product should support the use of customized security messages. This will enable an administrator to customize messages to fit the needs of his/her organization Common Control Language Across All Platforms (SAMA R15). The product should feature a common control language across all serviced platforms so that administrators do not have to learn and use different commands on different platforms Ability to Recreate from Logged Information (SAMA R16). Information logged/recorded by the system should be able to be used to "backout" changes to the security system.. For example, if several-users were deleted by mistake, the logged information could be inserted in a script to recreate them exactly as before deletion. This enables mass changes to be "backed out' of production or enables mass additions to be made based on logged information. Page 139 of 173

147 Administration for multiple Platforms (SAMA R17). The product should provide for the administration of the product for any of the supported platforms. This enables the administrator to support the product for any platform of his/her choice Ability to Create Security Extract Files (SAMA R18). The product should have the feature to produce an extract file of the security structure and the logging/violation records. This enables an administrator to determine which applications, nodes, domains or enterprises are being used and to what extent they are being used Test Facility (SAMA R19). The product should include a test facility to enable administrators to test security changes before placing then into production. This ensures that all security changes are tested fully before being placed into production. 7.6 General Functionality Backward Compatible (GFR E01). All releases of the product should be backward compatible or release independent. Features of new releases should co-exist with current features and not require a total reinstallation of the product. This ensures that the time and effort previously invested in the prior release of the product is not lost when a new release is installed Conformance to Standards (GFR E02). The product should be able to interface with existing application, database, or network security by way of standard security interfaces. This will ensure that the product will mesh with existing security products installed. Where possible, the product must conform to the known and accepted international standards. This will go a long way in ensuring that the product is flexible and "future proof" Phased Implementation (GFR E03). The product should be able to be selectively implemented for individual users, systems or resources to enable ease of implementation and migration for legacy systems. This will also allow the product to be 'phased in' Scalability (GFR E04). The product must not be limited to a specified number of users, domains or other restraints. It must be able to expand with the enterprise environment without logical or physical limits or degradation of performance. Page 140 of 173

148 7.6.5 Consistent User Interface (GFR R04). The product should have a common and familiar procedure for users to gain access to their systems and applications. The reduction in the number of times a user has to enter repetitive user ID and password information to access different applications on differing systems should help to increase the speed and efficiency of the users Ease of Use (GFR R05). The product should make use of a standard GUI interface that is both consistent and intuitive to use. The interface may vary slightly between platforms (i.e. Windows, OS/2, Xwindows, etc.) but should retain the same functionality. This ensures operating consistency and lowers training needs Flexible Cost (GFR R06). The cost of the product should be reasonable. Several cost scenarios should be considered such as per seat, CPU, site licensing and MIPS pricing. Pricing should include disaster recovery scenarios Certification (GFR R07). The author is of the opinion that products should be certified in terms of acknowledged international standards, i.e. ITSEC E2 Level, C2 level of the US Orange Book. This will give a more accurate measurement of the security level obtainable if the product is properly installed and configured One Single Product (GFR R08). The product should be a single product, not a compendium of several associated products. Modularity for the sake of platform-to platform compatibility is acceptable and favored Software Release Distribution (GFR R09). New releases of the product should be distributed via the network from a single distribution server of the administrator's choice. This enables an administrator to upgrade the product on any platform without physically moving from platform to platform Compatibility and Interoperability with Internet technologies (GFR R10) It is the author's opinion that cognizance should be taken of the emerging demand for Internet capable products. SSO products should thus provide Web-based security functions, as well as provide for very large user populations as can be expected with users on the Internet. Page 141 of 173

149 7.7 Conclusion All of the above requirements may not be applicable in every enterprise environment, but serious consideration should be given to the underlying principles. Alternative implementation of the mechanisms mentioned, may be applicable. These requirements can be incorporated in a framework for evaluating SSO solutions, thus enabling a rational and unbiased method of comparing SSO products. The next chapter attempts to do just that - to present a framework for evaluating and selecting SSO solutions. The next chapter will describe a methodology, consisting of seven phases, for the practical utilization of these requirements to enable selection of suitable SSO products. Page 142 of 173

150 Chapter 8 8. Evaluating, Selecting and Implementing SSO Solutions 8.1 Introduction The purpose of this chapter is to present a framework for evaluating, selecting and implementing SSO solutions. It presents a high level process for selecting the correct type of SSO solution for the enterprise, followed by a decision model for the essential and recommended functionality for a SSO product, and proposes a process for selection, based on which the appropriate SSO product can be selected, piloted and implemented. 8.2 General Considerations There are a few general considerations that should be. noted and borne in mind when engaging in the process of evaluation, selection and implementation of SSO solutions: Because of the emerging technologies involved, there is a very real possibility that key decision makers will not understand or grasp the significance of the differences between the technologies under consideration. Due care should be taken to present the full picture, with the strategic and management aspects highlighted together with technical features. There might be a tendency to favor known techniques like scripting, which may not be the appropriate solution. It is imperative to understand and manage the expectations of management. SSO may be perceived as a 'wonder cure' which will right other wrongs, like bad architectural planning, or implementation, and provide all the functionality needed without any sacrifice in performance, logistical support or changes to future architectures. To deliver on the promise of secure single sign-on, an organization must adopt an integrated enterprise security model, which provides support across heterogeneous operating systems and platforms. By adopting a centralized security solution, the organization establishes a common service that can be used across all applications and Page 143 of 173

151 databases. (Open Horizon, 1996) This may actually lead to security and single sign-on dictating IT Architectural decisions in future! The total Information Security and possibly Physical Security Architecture should be considered: It may be possible to integrate tokens for physical access control with the very tokens needed for logical authentication and access control. It may furthermore be possible to use the same role profiles and underlying security mechanisms for application level security, i.e. determining user roles within applications, setting transaction limits, etc. The ultimate dream of any security manager can thus be achieved: Having a single view of every user's security profile in the enterprise, be it physical, logical, system level or application level! The management and logistical support issues must be considered and the necessary structures put in place to ensure that the solution can be supported after the implementation project. This includes aspects like key management, trusted centers, Certification Authorities and Help Desk staff. Ongoing user training should not be forgotten. 8.3 The strategic SSO process There are a number of common factors in achieving successful single sign-on implementations. Foremost among these are: ensure that the business case for single sign-on is well motivated treat single sign-on as a strategic initiative invest the time and resources needed to understand the business environments in which single sign-on will function introduce single sign-on using a phased approach select favorable circumstances for pilot implementations implement single sign-on using multidisciplinary teams, representing all interests Stanley et al (Stanley, 1996) proposed a seven-step approach to implementing Single Sign-on. Page 144 of 173

152 After consideration, two additional phases were added by the author, namely Phase 1 and.1 Phase 6, as illustrated in figure below. The rationale for adding these phases will be discussed in detail when the individual phased are described. Phase 1 Phase 9 N I Agree Business Case for Single Sign-on i Phase 2 Deal with Strategic issues Plan and Implement wider solution -e Develop 1 Strategy for Single Sign-on V Phase 3 Agree environment for pilot implementation 0D 0 Build confidence and expertise Phase 4 t\ Phase 5 N. Phase 6 Phase 7 I\ Define the is Prepare Mobilise i initial - h Team 1 III. business i,,, available requirement 1* products Select Li S ortlist of t suitable Lo. 1:4.: >,;;\. Nfr.,,,...`' e.",'.0.,,nanges:-:, solution,5 Phase 8 Implement pilot Icy Figure 8.3.1: Overview of the suggested SINGLE SIGN-ON Implementation approach The goals of the approach as a whole are to: identify and prioritize opportunities for introducing single sign-on select single sign-on solutions which are compatible with the organizations oversell direction and strategy for information systems rationalize sign-on disciplines and practices, bringing them up to a consistent standard across the entire population of users of target systems avoid incompatible solutions appearing in different areas of the business which can lead to a multiplicity of sign-on processes appearing by a different route win the support of business managers for a well-planned and achievable initiative The approach starts with the development of a coherent strategy for single sign-on. A pilot implementation is then carried out to: build confidence by demonstrating the success of single sign-on Page 145 of 173

153 develop the experience of the project team train administrators and support staff Finally, the strategy is fulfilled by planning and implementing the single sign-on solution more widely. Main Phases Agree Business Case for Single-Sign-on Develop strategy for single sign-on Agree environment for pilot implementation Mobilize team Define me initial business requirement Prepare Shanlist of avaiiaole products Select suitable solution Implement pilot Plan ana implement wicer solution Key Steps Do cost-benefit analysis for SSO Prepare business case Agree and sign-off Business Case Identify strategic implications Identify interest and opportunities Agree single sign-on strategy Select type of solution Determine criteria for selection Evaluate opportunity areas Select favorable environment Confirm with business manager Determine range of experience needed Identify team members Fill gaps in know-how with outsiders Extend initial view of the requirement Assess target systems Agree detailed objectives Send out a Request For Information (RFI) Complete Product Checklist for each product Select most viable products Sena out a Request For Proposal trfp) Consider vulnerabilities and safeguards Select specific product Plan pilot implementation Acquire and install products Produce customized solution Implement pilot system Assess impact and performance Prioritize wider opportunities Produce implementation plan Confirm commitment Execute roll-out plan Table 8.3.1: Key elements of the suggested Single Sign-on implementation approach BA Phase 1: Agree Business Case for Single Sign-on The goal of phase 1 is to compile and agree a business case for Single Sign-on. It is common knowledge, that in order to get the required support and finance for a project of Page 146 of 173

154 this magnitude and potential impact, management should be convinced of the potential benefits for the company. This step is considered crucial, and was thus added to the suggested approach from Stanley et al (Stanley, 1996). This will provide the sound foundation for the project to build on Do Cost-benefit analysis for SSO As stated in Chapter 2, it can be extremely difficult to accurately assess the potential costs and benefits of SSO to the business. However, the 10% potential productivity gain (refer 1.1) can be used as a guideline. In some organizations, where the sign-on problem actually adds on to operating costs, by additional help desk calls, or where it leads to user errors during sign-on, costs can be assessed by calculating the costs for these activities. When considering potential benefits, the costs of administration of disparate systems must also be taken into account. Add to this the costs of actual and potential errors that could creep in as a result of this disjointedness, and the potential benefits of SSO with centralized administration features will become increasingly clear. If a SSSO solution is considered as opposed to a SSO solution, even more benefits will become evident. The added functionality, added levels of security and decreased administrative burden will not only lead to potential savings, but may also pave the way for exploiting new markets ( e.g. by having the appropriate levels of security for doing on-line banking or transacting on the Internet), and thus provide additional income! In addition. some insight could be gained by considering case studies of companies or other establishments that have already all or some of the SSO/SSSO functionality. The costs for the project can be calculated by using the figures presented in table Provision should also be made for product evaluation, pilot implementation and possible hiring of external consultants. Only a high-level budget should be presented at this time Prepare Business Case Once all the relevant costs and benefits have been investigated and considered, it should be properly documented as clear and concise as possible. Care should be taken to be as objective as possible and not to 'oversell' possible benefits. Because this step deals with trust and confidence at the strategic level, it is important that the business case should be as credible as possible. Where assumptions are made, they should be clearly noted as such. Page 147 of 173

155 8.4.3 Agree and sign-off Business Case After the business case has been prepared, it should be presented to all the possible stakeholders. It should be presented in such a way that it is easily understandable and the different business owners can relate to it in terms of their own business environments. The Business Case should be agreed to by the stakeholders and then signed-off. This is the crucial step, because it provides the commitment for the project to go ahead. This is the foundation on which a successful project can be built. 8.5 Phase 2: Develop strategy for Single Sign-on The goal of Phase 2 is to obtain support from business and specialist management for a well -informed single sign-on strategy. The strategy should take account of the strategic. implications of single sign-on and demand for single sign-on from business managers Identify strategic implications The strategic implications of single sign-on may be identified by discussion with the business and / or technical managers responsible for strategic planning of information systems and corporate information security. The strategic planning issues include: what commitment is there to introducing single sign-on as a strategic development? What types of computer systems or networks are currently employed, and what changes are expected? Corporate Security issues to be explored include: how can single sign-on best support the development of consistent standards for sign-on practice( e.g. format of userids and passwords, password complexity and change rules)? Can single sign-on be used to minimize the duplication of effort involved in administering users of multiple systems? Should single sign-on be a key part of an overall information security architecture? Identify interest and opportunities In parallel, the demand for single sign-on from business managers should be identified, initially in outline, rather than detail. The aim being to find business areas where: worthwhile benefits are achievable with available sign-on solutions there is support for its implementation Page 148 of 173

156 Demand may be identified by systematic study of the requirement for single sign-on, or by less formal techniques (e.g. raise awareness among business managers and invite them to put forward possible opportunities; table the subject for discussion by key groups of decision-makers knowledgeable about the business; or use existing knowledge). Whichever process is adopted, the key facts to be collected about possible areas of opportunity are: identity of the business area/ function and the business manager responsible for it key characteristics of users and target applications, including their criticality nature of the sign-on problem being experienced business impact of the sign-on problem the type of platforms access by users developments expected in the business area concerned It is recommended that a form for recording key information about each area of opportunity is drawn up and used as method of formally collecting and recording of data. Refer to figure below for suggested form that can be used for recording information about opportunity areas. Page 149 of 173

157 Single Sign on in Heterogeneous Computer Environments CHECKLIST FOR DEFINING SSO OPPORTUNITY AREAS Business area / Function I Business Manager Users Number of users? Number of userias/ oassworcs :ter typical user? Do users always wor% on their own workstation? Do users recuire access from workstations off-line? Target Applications Application Numoer of accesses by :pica' user per gay Package based or tailor-made Any users from other business areas Platforms used Reference Name Al A2 A3 A4 AS Business Cri leak How critical to tne ousiness are me following: Low Medium High Comment Response times of target systems? Continuity of access to target systems? Integrity of information processed oy target systems? Confidentiality of information processed by target systems? The Sian-on problem Business issuer Impact on the ousiness area Multiple sets of sign-on data to remember per user Users have to sign-on repeatedly per day Users have to oe registered on multiple systems Users have to master diverse sign-on processes Passworcs easily guessaole Passworcs written down Passworcs Shared Passworcs forgonen Wasted effort Wastea time Duplication of effort Inconsistent updates De-registrations overlooked Prolonged learning curve Unwanted complication Sign-on data liable o be compromised by: lax user discio ines (e.g. snaring of passwords) interception and transmission 'spoofing' the interception oy simulating a remote target system Dissatisfied users Inefficiency Business Process Inefficiency System Administratio n Security status Risk of unauthorized access How significant an impact aces the sign-on proolem have on: Services provided to external customers? 'Services provided to internal customers? Costs of the business area? Profitability of the business area? Security of the business area? None Minor Severe Comment Platform Reference Applications Supported Hardware Where located Operating System Support ng Network Number of users Use by other business areas Al A2 Page 150 of 173

158 A3 A4 A5 Developments expected What changes are expected over the next two years? Comment Number of users? Number of target application systems? Status of target application systems? Underlying platforms? Underlying networks? Assessment Business Manager Potential Benefit? User Population? Tolerant of 'glitches' supportive? Attractiveness Low/ Med/High Representative platforms Stable systems? Readily Isolated? Suitability for pilot? Priority for later roll-out? Figure 8.5.1: Checklist for defining SSO Opportunity Areas Agree single sign-on strategy The final step in phase 1 is to combine the information collected in the fact-gathering steps and use it to develop an overall strategy for single sign-on. The strategy should identify: business goals and priorities organizational focus (i.e. enterprise-wide or individual implementations) an implementation process decide in principal on the correct type of single sign-on solution Deciding on the correct type of Single Sign-on solution After gathering the information above, it should be possible to identify and agree in principal which type of single sign-on solution would be the most appropriate. In order to do this, the basic types of,single sign-on solutions should be reviewed against the business, technical and architectural characteristics of the enterprise environment: Synchronization Automated synchronization solutions may be an appropriate solution for business environments where: users require access to multiple systems, but tend to work with one system or another most of the time. In these circumstances, synchronization helps users remember their sign-on data and the continued need for manual sign-on is less of a disadvantage business systems are supported by a relatively simple architecture, featuring platforms and systems in widespread use, e.g. UNIX, or an IBM mainframe linked to Novell Netware servers Page 151 of 173

159 introducing consistent sign-on policies, conventions and practices is both desirable and feasible ( e.g. centralist style of management and centralized security administration) the vulnerabilities associated with insecure target systems or transmission can be safeguarded or the associated business risks are acceptable Scripting Scripting may be an appropriate solution for business environments where: users require access to several target systems over the course of a day. In these circumstances, users obtain repeated advantage from the automated sign-on process offered by scripting. users require access to applications on a wide variety of platforms (scripting can provide access to virtually any type of system) adequate resources are available to develop and maintain scripts, make them available to users and deal with day-to-day problems the vulnerabilities associated with insecure workstations or transmission can be safeguarded or the associated business risks are acceptable. Storing scripts on workstations or smart cards is appropriate for small groups of users, working in fixed locations. For large, mobile populations of users, a serverbased approach is likely to be more economical, flexible and secure. (Stanley, 1996) Proxies and Trusted Hosts. Proxies and Trusted Hosts are not considered as appropriate solutions where security is important for the business environment. It can only be used in low-risk isolated environments, with well controlled or non-existent links with the outside world Trusted Authentication Server solutions. A trusted authentication server solution may be an appropriate choice for business environments where: business processes have high integrity and/ or confidentiality requirements ( in these circumstances, the strong authentication provided by trusted authentication server solutions may be an important advantage) users require rapid access to several systems over the course of a day. In these circumstances, users obtain repeated advantage from the efficiency of the automated sign-on Page 152 of 173

160 users require access to applications on a restricted range of modern platforms from major manufacturers, running client-server applications with few or no legacy systems ' work is organized in terms of business units or work groups, user administration being seen as a task performed at this level rather than on a system-by-system basis there is a desire to streamline system administration user population are large and/or mobile the vulnerability associated with exchanging credentials between target systems can be safeguarded or the associated business risks are acceptable. (Stanley, 1996) Hybrid Solutions Hybrid solutions can be used in business environments where: users require rapid access to multiple systems over the course of a day. Users will obtain repeated advantage from the efficiency of the automated sign-on process offered by trusted authentication server solutions some business processes have high integrity and/or confidentiality requirements users require access to applications on a wide range of platforms and systems, including legacy systems user populations are large and mobile the possible vulnerabilities associated with the constituent parts of the solution exchanging credentials between target systems, insecure transmission of scripts) can be safeguarded or business risks accepted Comparison of SSO Approaches The different approaches, together with aspects like business impact, introduction of possible vulnerabilities and illustrative costs are summarized in the table below. Proxies and Trusted hosts are not included, as it is not considered a viable contender where an acceptable level of security must be maintained. Refer to Table Page 153 of 173

161 Feature Synchronization Smart Card Based Scripting Workstatio n Based Server Based Trusted A uthentica -lion Server Hybrid Maturity Mature Well -established Emerging Emerging Platforms Supported Restricted Virtually all Restricted but Increasing Capabilities provided Single set of sign-on data per user Automated sign-on Single point of administering users Opportunity to standardize sign-on practices Sign-on processes upgraded to a high common standard Business Impact Increased user satisfaction Increased user efficiency Increased efficiency in administering target systems Reduced risk of unauthorized access Audit trails across target systems El M M El 0 M 0 F3 M Virtually all M E3 El M 13 El n 0 2 Modest El 0 El El Modest El El El El El El a El El El 0 El El El Possible vulnerabilities Single point-of-failure Multiplied access Insecure storage Workstations Insecure storage :Target Systems Insecure storage :Servers Insecure transmission Insecure credentials E E M B 0 El El 0 0 E a El a a a El El El El a a a E a a E El g El El El la 0. Illustrative costs Software cost per user (assuming 100-user installation) Card readers (cost per workstation) Script development and maintenance Modification of target applications required Business Suitability Suitability for critical business processes Ideal applications accessed per day by a typical user Suitability for diverse target systems Max user population Suitability for mobile business users $25475 a a El One Med High Low $50-$100 $50-$100 $50- $100 $250- $500 a E El El 0 El la a Med El Med Several - Several Several High High High Low Low High Low Low High $100-$200 a a 0 El Several Medium High High $150- $300 a a - - Several High High High Table : Comparison of SSO Approaches (adapted from Stanley,1996) Page 154 of 173

162 After agreement has been reached on the type of single sign-on solution to be utilized, the field of possible choices can be narrowed considerably and can be progressed with more focus. The next phase is to select an area for piloting. 8.6 Phase 3: Agree environment for pilot implementation Determine Criteria for Selection To maximize the prospects of success, the pilot should be limited in scope, Key criteria for selecting the most favorable environment for the pilot implementation are: the business manager responsible should be supportive users should require to access multiple systems, face a significant problem in having to sign-on repeatedly using multiple passwords, and be able to tolerate any 'glitches' which emerge during the pilot implementation the population of users should be small to medium (e.g users) target systems should be all of the same general type, representative of those in use elsewhere in the organization and not likely to change over the life of the pilot it should be easily possible to isolate target systems from those used by other parts of the organization Evaluate Opportunity Areas Once the criteria are set, the available opportunity areas should be evaluated. Information gathered during Phase 2 can be used. Refer to Table Select Favorable Environment The most suitable environment for a pilot implementation must now be selected. This must be done by using the criteria set in 8.6.1, conjunction with identified opportunity areas as evaluated in Confirm with Business Manager After selection, the business manager responsible for the environment should be briefed on what the pilot entails and his or her agreement to the exercise confirmed. 8.7 Phase 4: Mobilize team The goal in phase 3 is to mobilize an implementation team with the credibility, knowledge, skills and motivation needed to make the pilot a business and technical success Determine range of Experience needed The first step is to identify the range of experience needed by the team members. The team should be familiar with: Page 155 of 173

163 working in the pilot environment defining business requirements (including information security requirements) administering target systems selecting, customizing, installing, running and supporting new systems introducing single sign-on ( alternatively, the team should have access to people who have access to people who have the necessary experience - using specialist consultants if necessary) Identify Team Members Once the range of skills have been identified, people that possess these skills within the company must be identified and their availability for the project assessed Fill gaps in know-how with Outsiders There is bound to be areas in which skills are lacking, or people with those skills are not available to the SSO project. In these cases provision should be made to bring skills in from the outside. These could be consultants, contractors or a team from a SSO product supplier. 8.8 Phase 5: Define the initial business requirement The first task of the implementation team should be to define the business requirement for the pilot implementation Extend initial View of Requirement Details already captured in Phase 2 will need to be probed and enlarged upon to ensure full understanding of: the business mission of the pilot environment users' working practices the target systems to which users require access and the purpose for what they are used information security requirements existing levels of performance desired improvements Assess Target Systems It is important that the team understands the key features of the target applications and the platforms on which they run. The nature of underlying networks should also be understood and any vulnerabilities highlighted. Page 156 of 173

164 8.8.3 Agree detailed Objectives This information will equip the team to set detailed and realistic objectives for the pilot implementation and agree them with the business manager responsible for the pilot environment. 8.9 Phase 6: Prepare shortlist of available products The selection process has been simplified by selecting the type of solution in phase 2 The suitability of particular products should be assessed Send out a Request For Information (RFI) Probably the quickest and easiest way to get product information, is to prepare and send out a Request For Information (RFI). The RFI is a structured questionnaire, prepared by the project team to extract all relevant information regarding the product, company and price structures. All possible suppliers will be requested to respond with the information on their offerings. The reply should be in the required format and delivered by a set deadline. When the information is received, it can be easily assimilated and evaluated against a product checklist Complete Product Checklist for each product The product checklist (Table ) below can be used to prepare a shortlist of the most viable products available. This is an essential step to speed up the process Select most viable products The most viable products are now selected for further evaluation. If the available products are not 'filtered' before the detailed selection process, the task of evaluating products in Phase 6 may become a time-consuming and a logistical nightmare. Ideally, no more than three products should be put forward for evaluation in Phase 6. Page 157 of 173

165 PRODUCT CHECKLIST Issue Key Questions Responses Coverage What platforms are currently supported? Are all platforms on the target environment supported? If not, can the vendor provide a custom solution, specially tailored to meet your needs? What plans does the vendor have to cover other platforms in current / foreseeable use in your organization? Is the product DCE-enabled? Maturity When was the product first developed? How many installations world wide? How many installations are equivalent to those of the target environment? Can reference sites be contacted? Functionality Does the product provide: Single set of sign-on data per user? Hence less need to write down passwords fewer calls to system administrators Automated sign-on? Hence less effort, faster process Single point for administering users of target systems (changes need to be made only once) Opportunity to standardize sign-on procedures to a high common standard, i.e. efficient, secure sign-on process? Mutual authentication of users and systems? Vulnerabilities Does the product introduce new vulnerabilities and, if so, what needs to be done to safeguard the organization? Key vulnerabilities to consider are: Single point of failure Multiplied access Insecure storage on workstations, target systems, servers Insecure transmission Insecure credentials Capacity Can the product support: The user population in the target environment peak loads (e.g. sign-on's at start of day)? What configuration would be needed to achieve this target population? Scalability Can the product support the maximum potential user population enterprise wide? What configuration would be needed to support the maximum user population? Support What support will the vendor provide for the target installation: on-site assistance? Access to experienced individuals for advice and guidance? Help-line support? Can the vendor support a wider implementation covering all locations in which the enterprise operates? Costs Which of the following elements of cost are relevant to the solution put forward by the vendor, and what costs are quoted? Software for: Servers Workstations Target platforms Other Hardware: Servers Smart Cards/ readers Other Development: Installation Scripting/ API's/Database Conversion Other On-going Support Helpline Upgrades Other Table 8.9.1: Product Checklist (Adapted from Stanley,1996) Page 158 of 173

166 8.10 Phase 7: Select suitable solution The goal of Phase 7 is to select a single sign-on solution which meets the business requirement of the pilot environment and which is likely to work well in other parts of the organization. This is done by detailed evaluation of the products that made it to the Shortlist as described in Phase 6 above Send out a Request for Proposal (RFP) The suppliers on the short list are now provided with detailed SSO/SSSO requirements as identified below. Detailed information about the companies' current and future technical architectures should also be supplied. Because some strategic information about the company may be exposed to the supplier in this process, it is recommended that a 'Nondisclosure' agreement be signed by all the vendors participating in the RFP Select Specific Product Information received back from the vendors on the RFP can now be used to do a detailed comparison of the essential and recommended functionality as defined in Chapter Essential Functionality Figure below indicates the functionality considered Essential for a Secure Single Sign-on solution. These are the requirements that must be satisfied. Should a proposed solution not conform to all of the essential criteria, chances are that the solution will not live up to expectations and could introduce vulnerabilities into the enterprise computing environment. Reference Essential Functionality AUTH Authentication AUTH E01 Single Sign-on AUTH E02 Support common password rules AUTH E03 Support a Standard Primary USERID Format AUTH E04 Auto Revoke after a number of Invalid Attempts AUTH E05 Capture Point of Origin Information AUTH E06 Support Sign- on's from Variety of Sources AUTH E07 Ensure USERID Uniqueness ACL Authorization and Access Control ACL E01 Differentiated Administration Privileges ACL E02 Default Protection unless specified ACL E03 Ability to support scripting - DICA Data Integrity/Confidentiality/Availability DICA E01 No Clear Text Passwords Page 159 of 173

167 DICA E04 DICA E05 SAMA SAMA E01 SAMA E02 SAMA E03 SAMA E04 SAMA E05 SAMA E06 SAMA E07 SAMA E08 SAMA E09 SAMA EIO SAMA Ell SAMA El2 GFR GFR E01 GFR E02 GFR E03 GFR E04 Integrity of Security D8(s) Failsoft Ability Security Administration Management and Auditing Single point of Administration Role profile based Full Audit Trail Single Revoke/Resume for All Platforms Ability to Enforce Enterprise Security Rules Ability to Trace Access Scoping and Decentralization of Control Synchronization Across all Entities Real-Time and Batch Update Customize in Real-Time User Defined Fields Support Customized Reporting General Functionality Backward Compatible Conformance to Standards Phased Implementation Scalability Figure : Essential Functionality for a Single Sign-on solution Additional Recommended Functionality. Figure below lists the additional functionality recommended for s Single Sign-on solution. Although these items are not essential, much value can be added to the eventual successful implementation of a solution. Reference AUTH AUTH R08 AUTH R09 AUTH RIO ACL ACL R04 ACL R05 ACL RO6 ACL R07 ACL RO8 DICA DICA R02 DICA R03 DICA RO6 DICA R07 DICA RO8 DICA RO9 Recommended Functionality Authentication Authentication Server should be Portable Support Public/Private Key technology Support Tokens/Biometrics Authorization and Access Control Physical Terminal/Node/Address Control Single Point of Authorization Support Standard Ticket/Certificate Technologies Support Masking/ Generics Allow Delegation Within Power of Authority Data Integrity/Confidentiality/Availability Inactive User Time -out Commercial Standard Encryption Option for Single or Distributed Security Databases Inactive User Revoke Optional Application Data Encryption Key Management Page 160 of 173

168 SAMA SAMA R13 SAMA R14 SAMA R15 SAMA R16 SAMA R17 SAMA R18 SAMA R19 GFR GFR R04 GFR R05 GFR RO6 GFR R07 GFR R08 GFR R09 GFR R10 Security Administration Management and Auditing Support User Exits/Options Customizable Messages Common Control Language Across All Platforms Ability to Recreate from Logged Information Administration for multiple Platforms Ability to Create Security Extract Files Test Facility General Functionality Consistent User Interface Ease of Use Flexible Cost Certification One Single Product Software Release Distribution Compatibility and Interoperability with Internet technologies Figure : Additional Recommended Functional Requirements for a Single Sign-on solution. For detailed explanations of the requirements listed above, refer to chapter 7 of this paper Proposed SSO Selection process As stated previously, this thesis does not concern itself with selection criteria other than the functional requirements for a Single Sign-on solution. It assumes that the other related criteria like product maturity, installed base, supplier stability, level of support available, introduction of new vulnerabilities and cost, will be investigated. No reference could found for an actual selection process, which would assist in applying the criteria above in actual selection of suitable SSO products. It was then decided to develop a simple flowchart which would illustrate the process of selection, as well as the relationship and significance of the Essential and Recommended criteria. This is called the SSO Evaluation Flowchart, and is illustrated in figure below. The proposed reference framework for selection of Single Sign-on solutions consist of two main aspects, namely: Page 161 of 173

169 Firstly, considering the essential requirements. These requirements are not weighted. The decisions are binary and should the solution not conform to every requirement, it should not be considered further. Secondly, after the essential requirements have been satisfied, the additional recommended functionality should be considered. Unlike the essential requirements, these requirements should be weighted. The individual weights must reflect the individual needs of the enterprise environment. Having completed the two steps above, an objective comparison of the available Single Sign-on solutions can be made. The best candidate can then selected for piloting. Bearing in mind the possible pitfalls for the prospective buyer, it is prudent to pilot the SSO solution with a selected group of users in a well defined computing environment, after which full implementation can follow. Refer to figure below. Evaluate every proposed solution 1-10 against Essential. Criteria (Binary decision) oes th proposed solutio conform to all criteria? Proposed Solution not suitable Yes Evaluate every proposed solution against recommended functional requirements (Weighted decision) 0 Compare recommender functional equirement scores of all the proposed solutions Yes Figure : The SSO Evaluation Flowchart. Page 162 of 173

170 Plan pilot implementation It is important that the selected product supports the full range of products found in the pilot environment. Once a product is chosen, detailed plans for its implementation should be made by the implementation team, in conjunction with the supplier, and agreed with the business manager responsible for the pilot environment Phase 8: Implement pilot The goal of the pilot implementation process is to: acquire and install the selected single sign-on product produce a customized solution prepare and hand over the system for live running in the pilot environment assess the impact of the pilot system and its performance. The work involved in achieving these goals should be carried out in accordance with the organization standards and guidelines for procurement, systems development, installation and operation. The agreed tests an performance measurements should be conducted accurately and the findings published, so that no misunderstandings arise. This is essential to keep the project out of the internal political arena. Throughout the implementation period, users should be kept well informed about the progress and the impact of the single sign-on solution on their day-to -day activities Phase 9: Plan and implement wider solution Single sign-on enhances the way users interact with target systems, improves business efficiency and reduces the risk of unauthorized access to corporate systems and data. These benefits should prove attractive across the enterprise as a whole. Thus, on completion of the pilot implementation, steps should be taken to plan and implement single sign-on more widely. A systematic study of opportunity areas should be conducted, if not already completed in phase 2. Identified opportunity areas should be ranked in terms of priority. Page 163 of 173

171 The work involved in developing scripts and / or adapting target applications to single sign-on should also be assessed and a detailed plan prepared for implementing single sign-on more widely. The detailed plan should be reviewed by business management and their commitment to its implementation confirmed. Expectations should be managed to ensure they remain realistic and achievable. The final requirement is to execute the roll-out plan. The experience gained by the implementation team for the pilot should be invaluable in ensuring the roll-out is a success Conclusion By following the structured approach presented above, the correct type of single sign-on solution can be selected, the most suitable product chosen and piloted under controlled circumstances. It is essential to make sure that key decision makers are aware of the significance of the differences between technologies considered, manage their expectations, and ensure their commitment by a well researched and prepared business case. The impact on, and possible integration with other security architectures within the enterprise should be considered, as this could add significant benefits. The added benefits of implementing a SSSO solution as opposed to a SSO solution should also be considered. This may eventually lead to implementing a totally integrated secure single sign-on solution capable of enterprise-wide security management, administration and auditing functionality. By following the nine steps of the proposed implementation approach, commitment, enough knowledge, experience and confidence can be gained to ensure the successful implementation of the chosen single sign-on product, while minimizing possibility of added risks and vulnerabilities. Page 164 of 173

172 Chapter 9 9. Conclusion and Recommendations Using traditional security approaches with today's heterogeneous computing environments can make systems unusable, lead to reduced productivity and potentially compromise the security of the systems. By introducing single sign-on functionality alone, only some of the security issues, like sharing of passwords and enhanced productivity will be addressed, but other vulnerabilities like single points of failure, multiplied access, insecure storage and insecure transmission of sign-on data, may be introduced. These vulnerabilities can only be addressed by taking a holistic view of the total enterprise security environment and implementing a properly architected Secure Single Sign-on (SSSO) solution, which provides the total or partial integration of the required security services, namely: Authentication, Authorization/Logical Access Control, Security Management and Administration, Auditing, Cryptographic services, Key management, Integrity, Confidentiality and Availability. The Selection a suitable SSO solution is not a trivial task and due care should be taken with the evaluation of SSO products, to avoid the pitfalls of introducing new vulnerabilities to the enterprise computing environment. Available products are generally immature and the potential benefits poorly understood and frequently oversold. Five different types of solutions were identified, namely: Synchronization, Scripting, Proxies and Trusted Hosts, Trusted Authentication Server and Hybrid solutions. Of the available types of solutions, only Trusted Authentication Server and Hybrid solutions can provide Secure Single Sign-on if properly implemented. In considering the different enabling technologies, it appears that: DCE and SESAME provides more and better integrated security services; The DCE approach has the greatest market momentum and is now favored by IBM to replace the NetSp niche; The interest being shown by software products companies in DCE, starting with the database vendors (see Open Horizon, Chapter 6), is reinforcing this momentum; It is likely that SESAME will continue to have a strong influence, and that DCE and SESAME will converge; Both Kerberos and GSS-API will continue to play an essential role in SSO solutions; Public-key technology will become increasingly dominant; Page 165 of 173

173 Secure tokens will be essential to securely implement asymmetric encryption technology. As can be deduced from the varied approaches to SSO, variety of platforms supported and mechanisms used, careful selection and evaluation of products are essential, but it is clear that DCE will undoubtedly become the de facto standard for SSO in future. It is essential to make sure that key decision makers are aware of the significance of the differences between technologies considered, manage their expectations, and ensure their commitment by a well researched and prepared business case. The impact on, and possible integration with other security architectures within the enterprise should be considered, as this could add significant benefits. The added benefits of implementing a SSSO solution as opposed to a SSO solution should also be considered. This may eventually lead to implementing a totally integrated secure single sign-on solution capable of enterprise-wide security management, administration and auditing functionality. A structured and logical approach is needed to implement SSO solutions successfully. By following the nine steps of the proposed SSO implementation approach, commitment, enough knowledge, experience and confidence can be gained to ensure the successful implementation of the chosen single sign-on product, while minimizing possibility of added risks and vulnerabilities. Nevertheless, it is clear that a well designed and architected SSO solution can provide added levels of security and substantially reduce security administration and security management workloads and that Single Sign-on in heterogeneous computing environments will become an essential part of the Enterprise Security and Technical Architectures in future. One essential requirement for companies to survive in future, is to be able transact electronically over open, and sometimes very vulnerable networks. Global electronic transacting will increasingly rely on setting up and maintaining mutual trust relationships between companies. This can only be achieved when transacting partners can demonstrate the level of trust they deserve by conforming to internationally accepted and certified security standards. These goals can be achieved by adopting SSSO technologies as descibed in this thesis. My research on the aspect of Secure Single Sign-on and the functionality that emerging products offer, or plan to offer, has led me to believe that the focus has shifted from the Page 166 of 173

174 single sign-on functionality, to comprehensive integrated enterprise security management and administration solutions. Single sign-on will be only one of the many security features offered. Businesses should utilize this opportunity to align their information technology and technical architectures to take advantage of these technologies. The research subject for this thesis: 'Single Sign-on in Heterogeneous Computing Environments' has been fortunate in the sense that it has been timely, and many new products and technologies are currently emerging. It is also a 'hot topic' in many businesses, especially those who employ heterogeneous and distributed computing systems. The rate of new SSO product announcements, or enhancements to existing products during the past year, made it very difficult to stay abreast of the new developments, but also very rewarding. As student, I have gained tremendously in knowledge, and the practical nature of the thesis enabled me to prepare a position paper on Secure Single Sign-on for a major bank in South Africa, which has now led to a strategic Secure Single Sign-on project along the lines proposed in the thesis. Page 167 of 173

175 10. Bibliography Goldberg, Joseph. Facsimile Transmission from Blockade Systems Corp. North York, Ontario, Canada, M2M1L1,Mar 11 '96 The Georgia RACF Users' Group (GARUG) Single Sianon Functional Requirements, September18, 1995, Deloitte & Touche Taking the Mystery out of.. Single Sian On, n.htm Millennium Computer Corporation FirstStep (TM): White Paper, Security Management System with Single Sign-on Access for easy Migration to Secure Client/Server Environments, IBM KryptoKnight www/g-kk/extern/kryptoknight ICL Access Manager, Bailey, M. MQ Security, Transaction Systems Services, IBM (MO Security ref 145) Computer Associates CA-Unicenter/SSO Century Analysis, Inc. CAI-Net, A Simile Loon facility that offers universal security combined with ease of use, CKS MyNet MyNet Concepts and Facilities, Publication reference : MyCF0.01 Computer Associates CA-Unicenter/Sinale Sign-On.Concepts and Page 168 of 173

176 Single Sign-on In Heterogeneous Computer Environments Facilities v GartnerGroup CKS' MyNet Delivers Secure Single Sian-On, Information Security Strategies, Continuous Services, Research Note, April 29,1996, ISS: P- IAC-048. Microsoft Microsoft SNA Server, Microsoft And Proainet Announce Solution to Integrate Windows NT Security With Mainframe And AS/400 Security Systems, May 24, 1996, SNA Server 3.0 Enters Beta Testing, McKelly, C. IBM Directory and Security Security Server for OS/2 Warp, An IBM Software Server White Paper, IBM Personal Software Products, Austin, Texas, 29 April 96. IBM IBM to offer Single Sign-on, Computerworld, , V30, N21 May 20,1996, p4. Churchill, Barbara. J. The future of NetSP and Single Sian-on message, Networking Software Products Marketing, E57/B501, RTP 8/ AccessManager Sinale Sian On Security for TSB PhoneBank, AccessManager News, November 15,1995. ICL ICL Releases Only Sinale Sion-On Security For Windows NT and Windows 95 Environments, Press release 13 May Last Updated June 16,1996; Revised June 20, International Business Machines Macros and Interfaces, Resource Access Control Corporation Facility, Version 2 Release,2 SC , Page 169 of 173

177 Second Edition (September 1995), Poughkeepsie, NY Gregory,N. One Click, Many Services, ACO User Forum, 25 May 1994, Security- Single Signon using Proxies and Trusted Hosts, documentation/uf htm I. Open Horison Enterprise Client/Server Secure Single Sign-On OPEN HORIZON WHITE PAPER, htm. ISM AccessMaster ISM AccessMaster, n. htm Stanley, Alan (et al) Position Paper Single Sion-on, European Security Forum April RFC 1508 Generic Security Service Application Program Interface. September 1993 RFC 1509 Generic Security Service Application Program Interface. September 1993 Oppliger, Rolf. Authentication Systems for Secure Networks, ISBN , Artech House, Inc., Norwood, Ma 02062, IBM Secured Single Sign-on in Client/Server Environment (IBM SSSO), International Technical Support Organization, Document Number GG , August IBM IBM Secure Single Sign-on Questions and Answers ( IBM SSSO Q&A), IBM Distributed Computing.lnternet. Millikin,Michael,D. DCE: Building the Distributed Future BYTE, June Parker,Tom. (et al) SESAME V4 Overview Issue 1, December Page 170 of 173

178 Steiner,Jennifer,G. (et al) Kohl, J. & Neuman, C. Kerberos : An Authentication Service For Ooen Network Systems Project Athena, Massachusetts Institute of Technology, Cambridge, March The Kerberos Authentication Service (V5), Request for Comments 1510, Digital Equipment Corporation, September Page 171 of 173

179 11. Glossary of Terms 11.1 Terminology and Abbreviations 11.2 Terminology The terminology of the OSI Security Frameworks [ISO 10181] is used where appropriate in this document. In particular, in ISO 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. The term Directory Certificate is used to describe an extended form of the certificate, defined in the 1993 Directory Authentication Framework Standard [ISO ], that is used to associate an asymmetric cryptographic public key with information about the holder of the corresponding private key (most importantly the holder's distinguished name). In other documentation such certificates are also variously known as user certificates, public key certificates, or X.509 Certificates (after the ITU-T standard equivalent to [ISO ]). The extensions supported are some of those currently being proposed within ISO. 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 gender bias intended Abbreviations ACI Access Control Information ACL Access Control List APA Client Authentication and Privilege Attribute (server) Client AS Authentication Server Page 172 of 173

180 CA Certification Authority CAA Certification Authority Agent CCITT The International Telephone and Telegraph Consultative Committee, (now called ITU -T (q.v.)) CSF Cryptographic Support Facility CV Control Value DSA Digital Signature Algorithm ECMA European Computer Manufacturers Association. ISO International Standards Organisation ITU-T International Telegraphic Union - Telecommunications (previously CCITT, (q.v.)). KDS Key Distribution Server. LRA Local Registration Authority OSI Open Systems Interconnection PAC Privilege Attribute Certificate PAS Privilege Attribute Server PKM Public Key Management PPID Primary Principal Identifier PV Protection Value PVF PAC Validation Facility RACF Resource Access Control Facility RSA The Rivest-Shamir-Adleman (asymmetric) cryptographic algorithm SACM Secure Association Context Manager SMIB Security Management Information Base TTP Trusted Third Party Page 173 of 173

181