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