Smart card usage for authentication in web single sign-on systems

Transcription

1 HELSINKI UNIVERSITY OF TECHNOLOGY Department of Electrical and Communications Engineering Raymond Philip Causton Smart card usage for authentication in web single sign-on systems This thesis has been submitted for official examination for a Master of Science degree in electrical engineering on February 25, Espoo, Finland. Supervisor Instructor Professor Teemupekka Virtanen Kari Lehtinen MSc

2 TEKNILLINEN KORKEAKOULU Sähkö- ja tietoliikennetekniikan osasto Raymond Philip Causton Toimikorttien käyttö tunnistautumisessa web-palvelujen kertakirjautumisjärjestelmiin Diplomi-insinöörin tutkintoa varten tarkistettavaksi jätetty diplomityö Valvoja Professori Teemupekka Virtanen Ohjaaja FM Kari Lehtinen ii

3 HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF MASTER S THESIS Author: Raymond Philip Causton Name of the Thesis: Smart card usage for authentication in web single sign-on systems Date: February 25, 2002 Number of pages: 110 Faculty: Professorship: Supervisor: Department of Electrical and Communications Engineering T-110 Communications software Professor Teemupekka Virtanen Instructor: Kari Lehtinen MSc The misuse of the Internet has increased the need for a centralised access control and strong authentication methods. Because web-services have become increasingly distributed, and the need for both a centralised administration and a single sign-on solution have become even more relevant. The instigator of this study Elisa Communications Corporation (Elisa) participates in the Pro FINEID project that promotes the use of FINEID -certificate based digital identity in dealing with the authorities and e-business services. The aim of this study is to select the best access control and administration solution for protecting the extranet of the Elisa Research Centre, based on the requirement specification dictated by the author. The basic requirements for both single sign-on and smart card support are required from all candidate products. This study contains a market review of available commercial solutions from which some were selected for further testing by the author in the Elisa Research Centres laboratory. The winning candidate is described in more detail later, accompanied by the evaluation details as per the requirement specification. Both the tested, and many other products were able to satisfy the single sign-on requirement, but only one of the tested products was able to fulfil successfully the basic requirement of FINEID smart card utilisation for strong authentication. Keywords: Authentication, single sign-on, security, smart card, certificate, X.509 iii

4 TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ Tekijä: Työn nimi: Raymond Philip Causton Toimikorttien käyttö tunnistautumisessa web-palvelujen kertakirjautumisjärjestelmiin Päivämäärä: Sivumäärä: 110 Osasto: Professuuri: Valvoja: Sähkö- ja tietoliikennetekniikan osasto T-110 Tietoliikenneohjelmistot Professori Teemupekka Virtanen Ohjaaja: FM Kari Lehtinen Internetin väärinkäytösten lisääntyessä on ilmennyt tarve keskitetylle pääsynvalvonnalle ja vahvalle tunnistamiselle. Web-palveluiden muuttuessa yhä hajautetummiksi palveluiksi on syntynyt tarve kertakirjautumiselle ja keskitetylle hallintakoneistolle. Tutkielman toimeksiantaja Elisa Communications on mukana ProHST hankkeessa, jonka tarkoituksena on edistää henkilön sähköisen tunnistamisen ja asioinnin mahdollisuuksia. Tämän tutkielman tavoitteena on valita sopivin extranet-palvelun pääsynvalvonta- ja hallintajärjestelmä Elisan tutkimuskeskuksen käyttöön tutkijan tekemän vaatimusmäärittelyn pohjalta. Perusvaatimuksina järjestelmälle ovat sen kertakirjautumispohjaisuus ja sen kyky hyödyntää toimikortteja vahvan identiteetin tunnistuksen aikaan saamiseksi. Tutkielma sisältää katsauksen markkinoilla olevista kaupallisista tuotteista, joista vaatimusmäärittelyä parhaiten vastaavat tuotteet valittiin tutkijan testattavaksi Elisan tutkimuskeskuksen laboratorioon. Tutkielmassa esitellään tarkempi arvio vain valitun tuotteen vastaavuudesta asetettuihin vaatimuksiin. Kaikki testatut ja myös useat muista kaupallisista pääsynhallintatuotteista kykenevät kertakirjautumiseen, mutta testatuista tuotteista vain yksi kykenee todellisuudessa toteuttamaan asetetun kynnysehdon, eli hyödyntämään suomalaista HST-korttia ja siihen tallennettuja varmenteita. Avainsanat: Tunnistus, kertakirjautuminen, tietoturva, toimikortti, varmenne, X.509 iv

5 FOREWORD This thesis was carried out at the Elisa Communications Corporation s Research Centre. I would like to thank my fiancée Katri Talja and my mother Pirkko for their toleration and encouragement that has enabled me to complete this thesis. I would also like to extend my thanks to my father, Darryl Causton, for his suggestions and corrections that considerably improved the final manuscript. Espoo, February 25, 2002 Raymond Causton v

6 TABLE OF CONTENTS Abstract... iii Tiivistelmä... iv Foreword...v Table Of Contents... vi List Of Figures... ix List Of Tables... xi Abbreviations And Acronyms... xii 1 Introduction Background and objectives Problem statement Thesis organisation Definition of central terms and concepts Background Infrastructure Cryptography Hashing and message authentication Symmetric cryptography Asymmetric cryptography Public-key digital signatures Key exchange algorithms Public-key infrastructure Smart cards The X.509v3 certificate The LDAP directory PKI structure Trust models Cross-certification Authentication Protocols And Methods User ID / password authentication Basic authentication...28 vi

7 3.1.2 Digest authentication One-time passwords Biometric authentication Symmetric key based cryptographic authentication ISO/IEC timestamp based unilateral authentication ISO/IEC nonce based mutual authentication Public-key certificate based cryptographic authentication Unilateral authentication protocols Mutual authentication protocols Network authentication systems Kerberos system architecture Operation of the Kerberos environment Pitfalls of Kerberos V Public-key cryptography extensions to Kerberos V Single Sign-On Architecture Different single sign-on architectures Native plug-in SSO agent Helper application agent Reverse proxy architecture Reduced sign-on architectures Single sign-on on the web Credential passing methods Simple WebSSO scenario Rejection points Generalised single sign-on model Risk-Analysis Based Requirement specification Raw requirements Confidentiality and integrity Encrypted communication paths Secure key management Cryptographic access tickets Alternative method of ticketing Pluggable authentication method support Strong authentication support Transaction non-repudiation Fine grained access policy enforcement Availability Transaction atomicity Component redundancy Disaster recovery Incremental scalability Load balancing features Multi-platform availability Accountability and audit Centralised management framework integration Delegated administration Other features External application server support...62 vii

8 5.5.2 Future support for global authenticators Remote administrations Graphical UI for administration Database locations and supported formats Summary of requirements Commercial single sign-on product survey Computer Associates International: etrust Single Sign-On CyberSafe: TrustBroker DataLynx: Guardian Entrust: GetAccess Evidian: AccessMaster SSO Tivoli: SecureWay Policy Director Netegrity: SiteMinder RSA: ClearTrust Proginet: SecurPass Sync Unisys: Single Point Security Feature summary of surveyed products Selection process of the products to be tested Evaluation Of The Selected Product Evaluation background Netegrity SiteMinder Supported platforms SiteMinders functional components SiteMinder s architecture The SiteMinder test bench Structure of the sites to be protected The SiteMinder graphical administration user interface Product evaluation to requirement specification Evaluation results in table format Problems encountered in testing Conclusions Evaluation results Future trends...92 Bibliography...94 viii

9 LIST OF FIGURES Figure 2.1 The hashing process...8 Figure 2.2 MAC constructed from a hash-function...9 Figure 2.3 Symmetric encryption process...10 Figure 2.4 Asymmetric encryption/decryption process...11 Figure 2.5 Digital signature creation and verification process...12 Figure 2.6 Depiction of a smart card [13]...13 Figure 2.7 The beginning of a certificate, DN shown...17 Figure 2.8 The middle section of the same certificate, CRL Distribution Point shown...18 Figure 2.9 The end section of a certificate, Key Usage attributes shown...19 Figure 2.10 The FINEID CRL on Figure 2.11 Windows 2000 certificate path validation logic [18]...21 Figure 2.12 A sample PKI environment...24 Figure 2.13 Two adjacent PKI domains...25 Figure 2.14 Cross-certified PKI domains with multi-path trust...26 Figure 3.1 Simplest occurrence of basic authentication...29 Figure 3.2 Simplified Digest Authentication...30 Figure 3.3 Unilateral authentication with pre-shared key K and timestamp...34 Figure 3.4 Mutual authentication with nonces and pre-shared key...34 Figure 3.5 Simplified public-key based client authentication [25, p.384]...35 Figure 3.6 Unilateral authentication with PKC and synchronised time...36 Figure 3.7 Mutual authentication with PKC s...37 Figure 3.8 X.509 mutual authentication with synchronised time...38 Figure 3.9 X.509 mutual authentication with nonces...39 Figure 3.10 The Kerberos general architecture [10, p.81]...40 Figure 3.11 Kerberos V authentication steps...42 Figure 4.1 Native plug-in architecture...46 Figure 4.2 External agent architecture...47 Figure 4.3 Reverse proxy architecture...48 Figure 4.4 Reduced sign-on architecture...49 Figure 4.5 Cookie handling in the WebSSO environment...50 Figure 4.6 Illustration of multi-host SSO in the web environment...51 ix

10 Figure 7.1 Netegrity SiteMinder components and interactions...71 Figure 7.2 The SiteMinder architecture overview...72 Figure 7.3 SiteMinder X.509 client authentication process...75 Figure 7.4 SiteMinder test setup...76 Figure 7.5 The public jump page from netra3.rc.elisa.fi...78 Figure 7.6 SiteMinder administration console front page...79 Figure 7.7 The SiteMinder administration console...79 Figure 7.8 The agent configuration menu...80 Figure 7.9 The user directories...80 Figure 7.10 Directory configuration...81 Figure 7.11 Realms in the S/SSO policy domain...81 Figure 7.12 Rules for the ptiaa-realm...82 Figure 7.13 SiteMinder policy setup dialog...82 Figure 7.14 Certificate mapping in SiteMinder...83 Figure 8.1 Suggested S/SSO architecture...91 x

11 LIST OF TABLES Table 1.1 Abbreviations and acronyms... xiii Table 2.1 ASN.1 encoded X.509v3 certificate syntax [16]...16 Table 2.2 Possible values for the KeyUsage attribute [16]...19 Table 2.3 ASN.1 encoded X.509v2 CRL syntax [16]...20 Table 3.1 A typical one-time password sheet...31 Table 3.2 Alternative hexadecimal OTP-key representations...32 Table 5.1 Raw requirement specification...55 Table 6.1 Supported features in surveyed products...68 Table 7.1 Correspondence of the requirement specification to SiteMinders features...87 xi

12 ABBREVIATIONS AND ACRONYMS AAA Authentication, Authorisation and Auditing ACF/2 IBM Access Control Facility 2 ACL Access Control List AES Advanced Encryption Standard ANSI American National Standards Institute API Application Program Interface AS Authentication Server ASN.1 ASN.1 DER Encoding is a Tag, Length, and Value Encoding System ASP Active Server Pages ATM Automatic Teller Machine CA Certification Authority CBC Cipher Block Chaining CCITT Consultative Committee for International Telegraph and Telephone CGI Common Gateway Interface CRL Certificate Revocation List CVS Concurrent Versions System DCE Distributed Computing Environment DER Distinguished Encoding Rules DES Digital Encryption Standard DN X.509 Distinguished Name DSA Digital Signature Algorithm DSS Digital Signature Standard, see also DSA EJB Enterprise Java Bean EMV Europay, Mastercard and Visa EU European Union FINEID Finnish Electronic Identity GSS-API Generic Security Service API GUI Graphical User Interface HMAC Hash Message Authentication Code HTTP Hypertext Transfer Protocol IAA Identification, Authentication and Authorisation IEC International Electrotechnical Commission IETF Internet Engineering Task Force ISO International Standards Organisation ITSEC Information Technology Security Evaluation Criteria xii

13 ITU-T International Telecommunication Union - Telecommunication JSP Java Server Pages LAN Local Area Network LDAP Lightweight Directory Access Protocol MAC Message Authentication Code MD5 Message Digest 5 MIT Massachusetts Institute of Technology NIST National Institute of Standards and Technology ODBC Open Database Connectivity OS Operating System OTP One-Time Password PIN Personal Identity Number PKC Public-Key Certificate PKI Public-Key Infrastructure PKIX Public Key Infrastructure for X.509 Certificates (IETF) PSE Personal Secure Environment RA Registration Authority RACF Resource Access Control Facility RFC Request For Comments RIPEMD-160 RIPE Message Digest 160 RPC Remote Procedure Call RSA Rivest-Shamir-Adleman, a public-key crypto algorithm RSO Reduced Sign-On S/SSO Secure Single Sign-On SC Smart Card SDK Software Development Kit SHA Secure Hash Algorithm SIM Subscriber Identity Module SSL Secure Sockets Layer SSO Single Sign-On TCB Trusted Computing Base TGS Ticket Granting Server TGT Ticket Granting Ticket TLS Transport Layer Security URI Unified Resource Identifier URL Unified Resource Locator USB Universal Serial Bus WAP Wireless Application Protocol WebSSO Single Sign-On for WWW-Services VPN Virtual Private Network WWW World Wide Web X.500 The ITU Specified Directory X.509 Certificate Structure Standard Table 1.1 Abbreviations and acronyms xiii

14 1 INTRODUCTION 1.1 Background and objectives Originally, computer systems were very open in the sense that they were standalone machines with physical access control to decide who may access the data stored within the computing environment. With the arrival of terminal connections to mainframes, it became a necessity to develop the multi-user environment. The need for simple access control solutions to limit user access to various resources was subsequently developed. This worked well with plain userid/password pair in order to login to systems, because computers were still scarce and there were only a limited number of users. In time, local area networks began to connect the computers to each other resulting in multiple systems that require authentication. The number of passwords one had to memorise began to grow. Today, with the Internet and global connectivity to various computing systems together with the abundance of computers in a typical corporate network, the number of different user-ids and passwords has grown tremendously. People using these systems are faced with the difficulty of learning multiple credentials to different systems off by heart. Furthermore, so as not to over simplify the issue, every user normally has to change their passwords at least twice a year. The passwords are made long and difficult to remember, because well-administered computer systems enforce strict password quality requirements. Passwords are easily misplaced or forgotten when the number of credentials the users has to use grows. It also consumes precious working time when one has to login to multiple systems manually, because it requires some seconds to remember and type in the user-id/password combination on each system when access is needed. It has also been noticed that login time increases with every failed authentication attempt [1]. Another problem with multiple computer systems is that of management. When the number of systems and users grow, the task of keeping track of authorised users and the termination of no longer authorised persons becomes unbearable without good tools to automate the process of adding users to, and deleting users 1

15 from, all of these systems. A single sign-on infrastructure provides a solution to these two problems. Single sign-on is enabling technology for reducing the number of passwords one has to use daily when using heterogeneous computing platforms and services. One may think of single sign-on as a safe that holds the keys to all other resources that one needs to access. This safe is special, in the sense that one only has to open the safe with one key and all the other keys will automatically open the locks they have access to without user intervention. An ideal SSO solution tries to achieve single authentication to the entire computing environment, and preferably also central user management and access control. Unfortunately, a single sign-on infrastructure is useless if the authentication process is flawed or weak. Only, if the users are authenticated using so called strong authentication methods i.e. cryptographically enhanced authentication processes like public-key based authentication can one be sufficiently certain of the identity of the communicating subject. To enhance the security of the certificate based authentication method it is suggested that only smart cards are used for storage of the private key. If there is a possibility that the SSO infrastructure is communicating with a rogue party impersonating a legitimate user, then all the enforced policies and access control measures are useless. It is exactly as the mantra of computer security says, Every systems security is as weak as its weakest link [2]. Therefore, one has to keep in mind the layered approach of computer security infrastructure, where every successive layer of security is built on top of the assumed invulnerable lower layer. This is extremely relevant, because nowadays the complexity of systems has grown so much that it has become impossible to verify the security of an entire system. Therefore, today all pieces of software are built somewhat modularly to allow focusing quality assurance on a well-defined sub-component of the whole one at a time. This leads to the aforementioned, layered approach. 1.2 Problem statement In a traditional environment, every service requires authentication, and since they have no central authority, they are trusted to make the authentication decision on their behalf. In a pure SSO environment, the user is issued a "certificate of identity" validated once by the SSO infrastructure and all subsequent identifications are done by presenting this certificate to the services that request validation. This means a considerable reduction in the number of times one needs 2

16 to type in ones authentication credentials during a typical computing session where one uses two to three applications, which require some sort of identification. Unfortunately, there is no international SSO infrastructure standard as of November Because of this, every operating system has its own proprietary authentication and authorisation methods and processes. This is unfortunate, as the most natural and secure place for single sign-on functionality is to reside in the lowest possible level of an operating system the kernel. Most modern operating systems use username/password combinations; the best ones use pluggable authentication modules, which enable just about any sort of authentication method to be used, and finally, some legacy Unixes use proprietary authentication systems such as RACF, ACF/2 or Top Secret for authentication [1]. Due to the payload that legacy systems have to support, any general SSO infrastructure needs to support and trust these non-native authentication methods and implement a RSO-like system for mapping SSO access certificates to legacy systems authentication methods, while at the same time appearing transparent to the end-user. This functionality may be obtained using application proxies, -plugins or scripting hosts. The objective of this thesis is to evaluate what is the current state of strong authentication in single sign-on platforms, and to formulate a recommendation of an AAA -architecture for use in the Elisa Research Centre. The target computing environment is heterogeneous, and there is a strong need for centralised extranet user management. Therefore, the primary issue addressed in this study is to identify the requirements necessary for a successful S/SSO -infrastructure, identify and evaluate conforming products and select the best product for deployment. 1.3 Thesis organisation In chapter 1, the background for this study is introduced and the objectives are laid down. The problem is also described together with the definition of some central terms Technical background information is provided to the reader in chapter 2. In this chapter, technologies that are infrastructure components to single sign-on solutions are briefly presented. 3

17 In chapter 3, different authentication methods are explained. This includes basic authentication, both symmetric and asymmetric cryptography based strong authentication methods as well as the most widespread network authentication model, Kerberos. In chapter 4, the general single sign-on agent architectures are discussed and the distinction between web- and legacy single sign-on and reduced sign-on are explained with an emphasis on the possibilities the web model has to offer to facilitate strong authentication and access ticket operations. In chapter 5, the requirements, specified by the author at Elisa s Research Centre, for an S/SSO application are presented with accompanying justifications for the criteria. In chapter 6, a market survey of single sign-on products currently on the market is presented. In chapter 7, the best product and its test set-up is described in detail, and its compliance to the requirement criteria from chapter 5 is evaluated. Finally, in chapter 8, this thesis work is summarised and conclusions are made. 1.4 Definition of central terms and concepts Here the meanings of some central terms that I will use in this thesis are explained. Software architecture The architecture of a software system is the set of interfaces through which its functions are accessed, and the set of protocols with which it communicates with other systems. [3, p.5] Platform The term is used to mean the service- or computing environment. The collection of computing resources runs the single sign-on services and the host operating system. Protected service The resources of a service are protected by the secure single sign-on infrastructure. Client 4

18 Client is a program that establishes connections for sending requests. [4] Client environment This is the computing platform of the person requesting access to protected resources from the authentication and single sign-on infrastructure. This includes all applications and devices that are required to access the protected services. Server A server is an application program that accepts connections in order to service requests by sending back responses to the clients. Any given program may be capable of being both a client and a server; in this thesis, the use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behaviour depending on the nature of each request. [4] Proxy Proxy is an intermediary program that acts as both a server and a client for making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "nontransparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services; media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behaviour is explicitly stated, the HTTP proxy requirements apply to both types of proxies. [4] User agent User Agent is the client, which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. [4] Single sign-on SSO is the concept of using a single credential to gain access to all computing resources both locally and on the network. The used credential may include the use of passwords, tokens, certificates and other authentication methods for initial authentication. Reduced sign-on RSO is the concept of reducing the burden of signing onto multiple systems with different credentials. This, however, is not single sign-on, as typically the user 5

19 has to have multiple credentials even though he is using a reduced sign-on environment, which controls those credentials in everyday use. Authentication Authentication is the verification process to compare an electronically stored set of identification data supposedly unique to a given user, with the same data that the user inputs as their unique identifier, for comparison with the stored version. If the comparison is found to be true, then that user is authenticated as correct, so he can then be granted access rights (i.e. given authorisation) appropriate to that user. [4] Authorisation A generally accepted definition of Authorisation is "the granting of access rights to a subject (for example a user or a program)." [5, p.1] Audit Audit in this paper means the process of collecting transaction data to log-files for later analysis in case of a system malfunction, breach or other unusual circumstance. Detailed data of the systems usage history may be required for later analysis. Identification, Authorisation, Access Control The IAA abbreviation describes what an SSO system is supposed to provide to the network a service where the user is identified, authorised and subsequent access control is based on the previous authorisation. Authorisation, Access Control, Accounting The AAA abbreviation describes the complete computing platform in which SSO participates. The accounting part takes care of logging, auditing functions and possibly gathering billing information. 6

20 2 BACKGROUND INFRASTRUCTURE In this chapter, technologies that play a significant role in building and operating a single sign-on infrastructure and certificate based authentication systems are described. These include short introductions to cryptography, the public-key infrastructure, and its subcomponents. The content of this chapter strives to build on each previous topic. The relevant cryptographic methods are described first because these terms will be used throughout the entire study. Next building on the general understanding of cryptography, the public-key infrastructure and its components are described. PKI is essential for smart card authentication to function, because certificates would not exist without PKI. 2.1 Cryptography Cryptography plays a central role in modern authentication and single sign-onsystems. It is used in various ways from generating certificates, signatures, protecting data and traffic to storing credentials locally in a secure manner. The most common cryptographic transformations are briefly explained below Hashing and message authentication The hash functions are used for generating unique fingerprints of an arbitrary amount of data. This fingerprint is then utilised in digital signatures as the representative of the actual document that is signed. These fingerprints are also used for integrity checking purposes in the message authentication form. Hashing is the process of using a one-way mathematical function on a message M to render it into a unique fixed-size hash code as is shown in Figure 2.1 The hashing process from which the original object cannot be deduced in any way easier than simply guessing the original. The hash code is a function of every single bit of M, H (M), and therefore if any bit in M changes the correct hash code will change. [6, p.253, 7, p.429] 7

21 Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus legentis in iis qui facit eorum claritatem. Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius. Claritas est etiam processus dynamicus, qui sequitur mutationem consuetudium lectorum. Mirum est notare quam littera gothica, quam nunc putamus parum claram, anteposuerit litterarum formas humanitatis per seacula quarta decima et quinta decima. Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum. Data HASH(Data) FF:2A:45:12:DE:12 Figure 2.1 The hashing process Mathematically the significant property of hash-functions is collision resistance [6, p , 7, p.429]. This means that if a hash-function is collisions free no two different objects can hash to an identical hash-value. Because of which the hash of a message M, H (M) can act as a fingerprint -like unique identifying value of the message M. Hashes are typically used for storing passwords, message authentication and verifying the signatures of electronic documents. Three typical hash algorithms used are Secure Hash Algorithm (SHA), Message Digest 5 (MD5) and RIPEMD- 160 [6, p , 7, p , ]. A hash code can be used to provide message authentication i.e. integrity checking by appending the hash code as redundant data to the message M. Using a plain hash of the data is in itself insufficient, and therefore, a secret component needs to be added to the hashed message. These hash-functions are called keyed-hashes or message authentication functions [6, p.243, 7, p.455,]. This is displayed in Figure 2.2 MAC constructed from a hash-function below. 8

22 Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus legentis in iis qui facit eorum claritatem. Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius. Claritas est etiam processus dynamicus, qui sequitur mutationem consuetudium lectorum. Mirum est notare quam littera gothica, quam nunc putamus parum claram, anteposuerit litterarum formas humanitatis per seacula quarta decima et quinta decima. Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum. Data Password HASH(Data,password) FF:2A:45:12:DE:12 Figure 2.2 MAC constructed from a hash-function This differs from conventional hash-functions in that a secret key K is appended to the message M so that MAC = H (M, K) and an attacker cannot re-compute the hash from a modified message M simply by MAC = H (M ). Because he does not know the secret key K, this is impossible. MAC algorithms can be built based on conventional hash-functions or symmetric encryption algorithms with modifications to make them one-way. Popular MAC algorithms are HMAC [7, p.293, 8] and the Data Authentication Algorithm, FIPS PUB 113 [7, p.252] Symmetric cryptography With symmetric cryptography, the cryptographic function uses the same key for encryption and decryption as visualised in Figure 2.3 Symmetric encryption process and thus it is said to be symmetric. Symmetric cryptography is sometimes called shared-secret or secret key cryptography because the encryption/decryption key has to be shared between all parties authorised to access the enciphered data. Symmetric cryptography is used for the encryption of bulk traffic because it is less demanding on computer resources than public-key based cryptography [6, p.164, 7, p.416, 469]. In this study, symmetric cryptography is utilised for all traffic encryption tasks between clients and servers, and in access ticket encryption. 9

23 Plain text Cipher text Plain text Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus le Data Sender Password Symmetric Cryptographic Algorith sdajhdkjahsdklah3lm4# "345l k4hj65klj45h6kj45n6m45n62-5.m,6n43%&n3456n3.45k6h# %&HJ#: %K6h# :%M;&HL: K %H&LKJ %H&LK%H& % H&J %H_&J# %H&:# H%&: K%JH&:#45-634k.56#_ %6# %k6öl%&_ %Lj7_:JY;:JTYJ4:&K/ j56.k7j5.67j5.6k7j %K6j.5kj7.5 6j7.%/J%J/%&:/ j45&:7j56.j.6rk7j45.6k7j6.k7jas ytav j6.w sd fkasdjfklajsdlfk$ $ks,sdfaslhfa jsdhflkjs.,zxmcnadscfdfw454 tsam,.nvi<zoejrwta%656h45-645&&(/ )7nknnvljzxnvjsndfmnamfcDN VM:SFNV:DFMNGSgjhfshn5 6knskhf.kfK:JSDLKJGFLGJD FMNBF34k.56#_ sdfkasdjfklajsdlfk$ $k s,sdfaslhfajsdhflkjs.,zxmcnads cfdfw454tsam,.nvi<zoejrwta Data Receiver Password Symmetric Cryptographic Algorith Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus le Figure 2.3 Symmetric encryption process The downside of symmetric cryptography is the problem of key management, [6, p.164, 7, p.48] and the trustworthiness of those involved with the shared secret. William Stallings [6] remarks that public-key cryptography also requires a set of protocols for key distribution, and therefore is not a panacea for key distribution problems. The most common symmetric algorithms in use today are the Data Encryption Standard (DES) and 3DES a variant of DES with a triple length encryption key. More recent symmetric encryption algorithms include IDEA, Blowfish, Two Fish, Rijndael, etc. Rijndael won the contest to become the Advanced Encryption Standard [9], for the US National Institute of Standards and Technology. All of these newer algorithms use longer encryption keys than DES, which makes them much harder to compromise if no vulnerabilities in the algorithms themselves are uncovered Asymmetric cryptography Asymmetric cryptography, also known as public-key cryptography, is fundamentally different from symmetric cryptography. The difference between these two is in the level of secrecy of the encryption keys. In symmetric cryptography, it is of primary concern to keep the encryption key secret. In asymmetric cryptography, one has two different keys, the public key, which can be revealed to anyone and the secret key that is personal and must be kept secret [6, p.173, 7, p.467] as seen in Figure 2.4 Asymmetric encryption/decryption process. 10

24 Plain text Cipher text Plain text Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus le Data Sender Asymm.Algorith E PKB (data) sdajhdkjahsdklah3lm4# "345l k4hj65klj45h6kj45n6m45n62-5.m,6n43%&n3456n3.45k6h# %&HJ#: %K6h# :%M;&HL: K %H&LKJ %H&LK%H& % H&J %H_&J# %H&:# H%&: K%JH&:#45-634k.56#_ %6# %k6öl%&_ %Lj7_:JY;:JTYJ4:&K/ j56.k7j5.67j5.6k7j %K6j.5kj7.5 6j7.%/J%J/%&:/ j45&:7j56.j.6rk7j45.6k7j6.k7jas ytav j6.w sd fkasdjfklajsdlfk$ $ks,sdfaslhfa jsdhflkjs.,zxmcnadscfdfw454 tsam,.nvi<zoejrwta%656h45-645&&(/ )7nknnvljzxnvjsndfmnamfcDN VM:SFNV:DFMNGSgjhfshn5 6knskhf.kfK:JSDLKJGFLGJD FMNBF34k.56#_ sdfkasdjfklajsdlfk$ $k Data Receiver PIN-code Asymm.Algorithm D PrKB (cipher text) Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus le s,sdfaslhfajsdhflkjs.,zxmcnads cfdfw454tsam,.nvi<zoejrwta Figure 2.4 Asymmetric encryption/decryption process The main difference is that anyone can now send you securely encrypted material, which can be decrypted only with your private key the public key is not able to decrypt the encrypted data only encrypt it. These two keys are connected to each other mathematically in such a way that one cannot deduce the other without knowledge of the original generation prime numbers used to create the key-pair. The RSA algorithm is the most popular and widely used public-key algorithm on the market, named after its inventors Ron Rivest, Adi Shamir and Leonard Adleman. [6, p.173, 7, p.467] Public-key digital signatures The digital signature algorithm, DSA, was developed by the NSA and became the digital signature standard, DSS, of NIST in One of the main reasons DSA was chosen over the de facto standard RSA was the royalty freeness of DSA vs. the RSA patents and royalty requirements [7, p.486]. It was originally thought possible to generate only digital signatures and therefore be exempt from export restrictions. This assumption was shown to be in some cases false as demonstrated in the book Applied Cryptography [7, p ]. A digital signature is made by encrypting the hash of the document to be signed with the signer s secret key and by appending the resulting value to the document as shown in Figure 2.5 Digital signature creation and verification process below. This signature can be verified by calculating the same hash-function of the document and comparing this with the signed hash-value after decrypting it with the signer s public-key. 11

25 Plain text Signed data Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus le Data Sender PIN-code Asymm.Algorith E PrKA (H(data)) Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus le Data Receiver Asymm.Algorithm D PKA (signed data) Result Signature valid / invalid HASH = D3:E4:GF:23:AC:FF SIGN = as"44d%f6/ asdaasd#"s23f66jhj5349/ & csdfasdk Figure 2.5 Digital signature creation and verification process The RSA algorithm can also be used for digital signatures and nowadays it may be used without royalties, so there are not many reasons left to use DSA anymore as its signature verification is slower than RSA s [7, p ] Key exchange algorithms With key exchange algorithms, one can negotiate a symmetric encryption key for bulk data encryption in such a way that an eavesdropper cannot deduce the key from public information transmitted over the network in the key exchange negotiation. A very successful key exchange algorithm is the Diffie-Hellman key exchange algorithm [6, p.190, 7, p.513]. There also exist algorithms that implement this with public-key encryption utilising certificates [10, p.38]. 2.2 Public-key infrastructure The public-key infrastructure is the collection of services needed for successful deployment and use of digital X.509 certificates stored in smart cards, tokens or file containers. The purpose of a PKI is to support the user services based on public key certificates for security [11]. A public-key certificate is primarily used for generation of digital signatures, and identification based on a cryptographic challenge-response authentication protocol. The usage of PKC s for authentication is a natural progression from basic username/password authentication towards legally binding strong identification over a computer network. This chapter is segmented in the following logical order: first, the smart card i.e. the secure container for the secret key issued by the CA is described. Then the X.509 certificate and revocation list profiles are explained in order to provide the 12

26 reader with a general understanding of certificates. Once the certificate and the immediate storage device have been described, it is necessary to expand the discussion to include the directory. This is used for publishing the public part of a certificate, which enables other people to use the cryptographic services provided by the RSA public-key stored in the certificate. In addition, the revocation lists are published in similar public directories for on-line determination of the validity of a certificate. When combined, these technical components form a PKI framework. The chapter also includes a brief discussion of the administrative entities of a PKI such as the certificate and registration authorities as well as inter-domain trust relationship management in the PKI models Smart cards To provide secure storage for digital identification credentials it is advisable to use hardware tokens called smart cards. A smart card is the size of a credit card or a smaller SIM card, and it is equipped with an embedded microcircuit as shown below in Figure 2.6 Depiction of a smart card [13], which contains memory and a microprocessor together with an operating system for memory control. The smart card is a secure storage location for secret information. [12] This is called the personal secure environment, PSE. Figure 2.6 Depiction of a smart card [13] Contact smart cards must be inserted into a smart card reader. They have a small gold plate about 13 mm in diameter on the front, instead of a magnetic strip on the back like a credit card. When the card is inserted into a smart card reader, it makes contact with electrical connectors that transfer data to and from the chip. [13] 13

27 The card can store data such as personal information, money, or other information whose alteration or disclosure might be risky. The card may also store encryption keys, which the card user can use for tasks such as key exchange, network identification or digital signature. [12, 14] The smart card can also be used for decoding encrypted messages and for digital signatures. The card makes it possible to avoid reading the key into the computer for software encryption, which means that the risk of disclosure is considerably reduced. [12, 14] The basic technical properties of smart cards are Tamper-resistance Random Access Memory for data storage Processing capabilities (e.g. cryptographic co-processors) Tamper-resistance means that if an unauthorised party obtains a smart card it is very unlikely that he will be able to discover the contents of the microchip embedded into the card. Resistance to tampering with the card is achieved in various ways starting from physical obfuscation of data paths [12] on the chip and ending with evaluated secure card operating systems. Setec s SetCOS was the world s first card operating system to receive security evaluation at the E4 High level in accordance with the international ITSEC Criteria in 1996 [15]. The security of the smart card is based on both logical and physical security. Logical security means that the card does not leaks out information that should be kept secret. The logical security of the smart card is controlled by a secure operating system. [12] Physical security is related to the structure of the smart card chip. The aim is to make an unauthorised examination of the chip impossible, or at least very expensive. Address and data lines that logically belong together are intermingled in different layers. Phantom transistors are embedded in the circuitry to make examination more difficult. Upper and lower limits for clock frequency hinder the examination of the circuitry. [12] Some tokens might have physical self-destruction mechanisms, but these are devices mainly used by armies and intelligence services [2]. From a usability aspect the most interesting properties of a smart card are Personal Portability Easy to understand and use by the layman 14

28 It is worth making the distinction between a smart card and a memory card. While they are similar in appearance, a memory card is only suitable for disposable data storage. Memory cards are in general use as phone cards or other disposable means of payment. [12] A drawback to memory cards is their weak security. Unlike smart cards, they have no operating system that controls memory usage, and their use may be subject to the use of a card PIN-code. However, the protection of the memory card is not as strong and versatile as in a smart card. [12] In this thesis, smart cards are utilised to provide a secure, portable and strong authentication method, which can be used in a heterogeneous computing environment The X.509v3 certificate Certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. [16] In this chapter, the IETFs PKIX working groups definition of Internet operable profile for X.509v3 certificates and CRLs is introduced based on RFC 2459: PKIX X.509v3 certificate profile and X.509v2 CRL profile Definition of a certificate Users of a public key shall be confident that the associated private key is owned by the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained with public key certificates, which are data structures that bind public key values to subjects. The binding is certified by having a trusted CA digitally sign each certificate. The CA may base this decision upon technical proof of possession or by determining the applicant s identity by classic identification methods in person. A certificate has a limited valid lifetime, which is indicated in its signed contents. Because a certificate-using client can independently check a certificate s signature and timeliness, certificates can be distributed via untrustworthy communications and server systems, and can be cached in unsecured storage in certificate-using systems. [16] Certificate versions ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU , which was first published in 1988 as part of the X.500 directory recommendations, defines a standard certificate format [17]. The certificate format in the 1988 standard is 15

29 called the version 1 (v1) format. When X.500 was revised in 1993, two more fields were added, resulting in the version 2 (v2) format. ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) certificate format. The v3 format extends the v2 format by adding a provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organisation or community. In June 1996, standardisation of the basic v3 format was completed. [16] As of May 3, 2001 X.509 version 4 (v4) has been available as a draft specification from ISO/IEC/ITU Internet certificate profile The X.509 v3 certificate basic syntax is as follows in Table 2.1 ASN.1 encoded X.509v3 certificate syntax [16] encoded in the 1988 ASN.1 syntax. For signature calculation, the certificate is encoded using the ASN.1 distinguished encoding rules (DER) as described in ITU-T X.208. Certificate ::= SEQUENCE { tbscertificate TBSCertificate, signaturealgorithm AlgorithmIdentifier, signaturevalue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueid [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3 subjectuniqueid [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version shall be v3 } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notbefore Time, notafter Time } Time ::= CHOICE { utctime UTCTime, generaltime GeneralizedTime } UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectpublickey BIT STRING } Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnvalue OCTET STRING } Table 2.1 ASN.1 encoded X.509v3 certificate syntax [16] 16

30 As a concrete example, a certificate obeying this profile issued by the Elisa Communications Corp. test CA is presented here: Figure 2.7 The beginning of a certificate, DN shown In Figure 2.7 The beginning of a certificate, DN shown the Subject attribute aka Distinguished Name or DN is highlighted. It is noteworthy that the DN attribute is actually an aggregate of multiple attributes as can be seen in this picture. Namely, it consists of the attributes CN, G, SN, Serial Number, I, OU, O and C. These stand for CN = Common Name G = Given Name SN = Surname Serial Number = a unique serial number inside the CA who issued this certificate I = Initial OU = Organisation Unit O = Organisation C = Country. 17

31 There could be other attributes and the contents of these fields differ from subject and CA to another. Figure 2.8 The middle section of the same certificate, CRL Distribution Point shown In Figure 2.8 The middle section of the same certificate, CRL Distribution Point shown the CRL distribution point is highlighted because this enables the client software to validate the certificates validity when one attempts to use a certificate. If the CRL check is omitted or impossible, the trust model of a PKI is broken and one cannot trust the certificate. 18

32 Figure 2.9 The end section of a certificate, Key Usage attributes shown Lastly, the KeyUsage attribute is highlighted in Figure 2.9 The end section of a certificate, Key Usage attributes shown, to show the constraints for the usage of this particular certificate. As can be deduced from the above constraints this certificate is used for client authentication with digitalsignature, keyagreement and dataencipherment usage attributes as opposed to the second certificate on the example smart card. Its KeyUsage field states as the constraint NonRepudiation. It is therefore usable only for digital signature generation. Other possible values of the KeyUsage-attiribute are listed below in Table 2.2 Possible values for the KeyUsage attribute [16] : KeyUsage ::= BIT STRING { digitalsignature (0), nonrepudiation (1), keyencipherment (2), dataencipherment (3), keyagreement (4), keycertsign (5), crlsign (6), encipheronly (7), decipheronly (8) } Table 2.2 Possible values for the KeyUsage attribute [16] 19

33 The X.509v2 certificate revocation list One goal of this X.509 v2 CRL profile is to foster the creation of an interoperable and reusable Internet PKI. CRLs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and an even broader spectrum of operational and assurance requirements. This profile establishes a common baseline for generic applications requiring broad interoperability. The profile defines a baseline set of information that can be expected in every CRL. In addition, the profile defines common locations within the CRL for frequently used attributes as well as common representations for these attributes. The X.509 v2 CRL syntax is as follows in Table 2.3 ASN.1 encoded X.509v2 CRL syntax [16]. For signature calculation, the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encoding is a tag, length, and value encoding system for each element. CertificateList ::= SEQUENCE { tbscertlist TBSCertList, signaturealgorithm AlgorithmIdentifier, signaturevalue BIT STRING } TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- if present, shall be v2 signature AlgorithmIdentifier, issuer Name, thisupdate Time, nextupdate Time OPTIONAL, revokedcertificates SEQUENCE OF SEQUENCE { usercertificate CertificateSerialNumber, revocationdate crlentryextensions crlextensions } Time, Extensions OPTIONAL -- if present, shall be v2 } OPTIONAL, [0] EXPLICIT Extensions OPTIONAL -- if present, shall be v2 Table 2.3 ASN.1 encoded X.509v2 CRL syntax [16] As can be seen from this ASN.1 notation of the syntax of the CRL, a CRL consists of a signed list of serial numbers of all revoked certificates with corresponding revocation time stamps and possibly a reason code, if it is of version 2. Below in Figure 2.10 The FINEID CRL on the certificate revocation list of Dec of the FINEID directory is shown as Microsoft Internet Explorer presents it. 20

34 Figure 2.10 The FINEID CRL on The CRL may be stored and distributed via a directory (LDAP, X.500), a web or ftp server accessible via http or ftp or some other mechanism to provide the client with similar check-up capabilities such as OCSP as defined in [16] Certification path validation Certification path validation -procedures are based on section 10 of the X.509v3 specification. Certification path validation verifies the validity and path of trust of the users and issuers certificates. The path processing proceeds as shown below in Figure 2.11 Windows 2000 certificate path validation logic [18]. The basic constraint and policy constraint -extensions allow the certification path processing logic to automate the decision making process. [16] Figure 2.11 Windows 2000 certificate path validation logic [18] 21

35 With path validation logic, the validity of a certificate is checked against all possible revocation reasons from multiple sources including CRL-lookups. There can also be constraints on a certificate imposed by certification authority policies that can be effective on a certificate from higher up in the certification path Storage of secret keys Secret keys can be stored either in an encrypted container-file or on hardware tokens like a smart cards or USB-tokens. These two primary storage methods differ mainly in the PSE offered by the storage container. With storage files, some security is usually offered using conventional encryption to protect the secret keys. Unfortunately, regardless of the storage, protecting a secret key stored in a file can easily be duplicated, whereas hardware tokens are usually tamper- and replication resistant. The natural advantage of file-based certificate storage is the versatility of the format [19]. While it does not require any additional equipment to use, and it is easily transportable, it is a weak PSE. A token-device on the other hand, while usually requiring additional reading devices, offers greater protection of the secret keys. This offsets the versatility of a file-based solution [19]. Stealing a secret key is considerably harder with cryptographic tokens, because the keys are stored into a tamper-resistant area of the token [19]. They are stored in such a way that they cannot be copied or read directly, so one has to steal the physical token. With file-based containers, one can easily copy the secret-key container onto a floppy disk without risk of detection. Once the container is copied, an off-line attack can be mounted against its security measures without alerting the owner to the loss of the secret keys. As long as the certificate and its encryption keys are not bound to a person biometrically, one can only presume that the person using a certificate is the person who he claims to be, since anyone can use a certificate if the PIN code has been compromised and the token or container has been stolen. Such biometric solutions are becoming available on the market The LDAP directory A directory is in effect, a server or a distributed set of servers that maintain an information database of people. The stored information includes user names, network address, titles, addresses and other information about the user. [6, p.341] 22

36 The certificates are stored in directories similar to the telephone directories for easy access. The X.500 series of recommendations defines a very complex directory protocol-suite and its structure. The LDAP directory was created as a simpler alternative with support for the central X.500 features. This imposes a large burden on the directory access protocol since it should be as universal as possible, while at the same time enabling wide scalability to support numerous daily enquiries. The directory itself can consist of various types of databases so long as it supports the LDAP query protocol. [19] Typical commercial LDAP directories include the Netscape Directory Server, Oracle and IBM DB2 databases with LDAP frontends. An LDAP directory can be queried with all modern web browsers like the Microsoft Internet Explorer and Netscape Navigator as well as some LDAP browsers specially built for this function PKI structure A typical public-key infrastructure consists of A Certificate Authority (CA) who issues the certificates A Registration Authority (RA) who authenticates the requestor before it forwards the request to the CA, who will then issue a certificate for the requestor. An LDAP directory for storage of issued certificates, public-keys and Certificate Revocation List (CRL) information A token manufacturer and a pre-personaliser are also required if they are used for certificate storage. [11, 20] 23

37 Certification Policy (CP) and Certification Practice Statements (CPS) Hardware Token Manufacturer PDA LDAP CRL LDAP Public Keys Root Certification Authority A Subordinate Certification Authority A1 Subordinate Certification Authority A2 Subordinate Certification Authority A3 Registration Authority A2-1 Server Server Person Person Person Person Server Person Server Person Person Server Server Figure 2.12 A sample PKI environment As can be seen in the above Figure 2.12 A sample PKI environment there is a single root CA, three subordinate CA s and one RA. Here the root CA normally would be operated by a corporation s IT administration, while the subordinate CA s would represent the various departments, who take care of local user administration on behalf of the corporation s data administration. Usually, it is regarded as good practice to refrain from issuing end-entity certificates directly by the root CA. It is better to build a hierarchy of subordinate CA s below the root CA to take care of daily administration. [20] In particular, for a PKI to be successful all parts have to be reliable and the rootcertificate has to be in trustworthy hands, since the PKI model is built on trust, and that the root-certificate is non-corruptible. 24

38 2.2.5 Trust models The two primary trust models in use today are the strictly hierarchical model and the networked model. These models differ from each other in the fundamentals of the hierarchy structure Strictly hierarchical trust model In the strict trust model, there is only one root of a hierarchy. Here every entity trusts the integrity of the root certificate and each other because they all have a trust path available via the trusted root. This is depicted in Figure 2.12 A sample PKI environment. Here the only root is Root CA A and all other entities in the hierarchy below the root are subordinates to the same root. [20, 21] Distributed trust model In the distributed trust model, there are multiple adjacent PKI s with their respective roots and subordinates. Here every PKI is a strict hierarchical PKI for its domain, but having multiple independent PKI s it makes this a distributed architecture. This is depicted in Figure 2.13 Two adjacent PKI domains below. [20] Inter-domain trust relationships are established by means of crosscertification in this distributed trust model. Certification Policy (CP) and Certification Practice Statements (CPS) Hardware Token Manufacturer Certification Policy (CP) and Certification Practice Statements (CPS) PDA LDAP CRL LDAP Public Keys LDAP CRL LDAP Public Keys Root Certification Authority A Root Certification Authority B Subordinate Certification Authority A1 Subordinate Certification Authority A2 Subordinate Certification Authority A3 Subordinate Certification Authority B1 Subordinate Certification Authority B2 Subordinate Certification Authority B3 Registration Authority A2-1 Server Server Person Person Person Person Server Person Server Server Person Person Person Person Person Person Server Server Server Server Person Person Server Server Figure 2.13 Two adjacent PKI domains 25

39 2.2.6 Cross-certification In the strictly hierarchical trust model, there is a single root for all PKI participants and there is only one PKI. While this simplifies matters, it is unfortunately an impractical architecture from a policy perspective. A problem arose from having a distributed trust model with multiple PKI s that did not trust each other per default via a common root. To resolve the problem the concept of cross-certification was developed. When two PKI s wish to interoperate with each other they cross-certify each other, which occurs when the CA s in question digitally sign a cross-certificate, which in practice is a certificate that contains the counterparts public keys [6, p , 20]. When a client from below the cross-certification point tries to verify a certificate from another PKI domain, it seeks a route to check the validity and trust relationship by finding a trusted path via the cross-certificate. Certification Policy (CP) and Certification Practice Statements (CPS) Hardware Token Manufacturer Certification Policy (CP) and Certification Practice Statements (CPS) PDA LDAP CRL LDAP Public Keys LDAP CRL LDAP Public Keys Root Certification Authority A Cross Certification Root Certification Authority B Cross Certification Subordinate Certification Authority A1 Subordinate Certification Authority A2 Subordinate Certification Authority A3 Cross Certification Subordinate Certification Authority B1 Subordinate Certification Authority B2 Subordinate Certification Authority B3 Registration Authority A2-1 Server Server Person Person Person Person Server Person Server Person Person Person Person Person Person Server Server Server Server Server Person Person Server Server Figure 2.14 Cross-certified PKI domains with multi-path trust In Figure 2.14 Cross-certified PKI domains with multi-path trust three possible cross-certification paths are illustrated. In the first version, the root CA s crosscertify each other and subsequently both PKI domains have a trusted path between one another. A somewhat limited variation of the previous case can be seen as the arrow between CA A2 and root CA B. Here all of PKI domain B has a trusted path to all entities registered below CA A2 and vice versa. The most limited version of cross-certification described here is the arrow between CA A3 and CA B1. Now only the entities registered below CA A3 and CA B1 trust each other and the rest of the PKI domains A and B remain alien to one another. 26

40 All of these cross-certification paths may coexist in peace. Usually though if the roots cross-certify each other, all subordinate cross-certificates should be deleted for the sake of clarity. 27

41 3 AUTHENTICATION PROTOCOLS AND METHODS This chapter is supposed to give the reader a general understanding that there exists multiple methods of authentication, some more secure than others. There are some de facto standards in authentication such as basic authentication i.e. using a user inputted username and password combination. In this chapter, different authentication methods are described in order of complexity and strength. The most interesting authentication method concerning this thesis is of course the public-key certificate based authentication scheme described below. 3.1 User ID / password authentication Historically, the use of plain username and password combinations has been the most common method of authentication. Today, it is still the most prevalent authentication method in existence, and its demise is nowhere in sight. It is an outdated, insecure method, but easy to implement with minimal requirements on the user-terminals with regard to equipment and software. Due to this and large legacy payload, it will still be in use well into the 21 st century Basic authentication Basic authentication means a plaintext username/password pair, which is inputted into a dialogue box, a form or prompted for this information. Then the textual information is checked against a database of correct answers, which one stores in plaintext or in some hashed form in a text file or in a database within the authorisation system. 28

42 Terminal Password Server Database Req(password, UID) Enter UserID and Password Prompt(UID) Resp(password, UID) Send(UID) Prompt(Password) Send(Password) Auth(OK) Figure 3.1 Simplest occurrence of basic authentication In Figure 3.1 Simplest occurrence of basic authentication, the simplest way of authenticating a user ID and a password is depicted. Here the server asks the user to identify himself and after the user has supplied identification information, his user ID, the server prompts for his password and checks whether it exists on the system, and if the password matches the one stored in its internal password database. If there is a match, the user is granted access to the server. In a UNIX setting this would be the /etc/passwd or /etc/shadow file, which contains the pairs username in plaintext, and password in hashed form H (passwd, salt). Salt is a padding of bytes appended to the real password before hashing it to increase the number of possible hashes for one single password to make dictionary based password guessing attacks more time consuming. In the web environment the HTTP protocol specifies a challenge-response framework for a web server to request authentication credentials from a client by sending the client a 401 Unauthorised error message. The user-agent may respond to this challenge with an Authorisation-header field with the http-request. [22] This information is then sent unencrypted over the network to the service for authentication. If the given credentials are correct, the client is given access i.e. authenticated and authorised to access the service. When the identity of the client is established access control decisions can be made as dictated by the access policy of the service Digest authentication Like basic authentication, digest access authentication verifies that both communicating parties share a secret (a password); unlike basic authentication, 29

43 this verification can be done without sending the password unscrambled, which is the biggest drawback of basic authentication. [22] Terminal Server Password Database Req(H(password), UID) Enter UserID and Password Prompt(UID) Resp(H(password), UID) Send(UID) Prompt(Password) Send(H(Password)) Auth(OK) Figure 3.2 Simplified Digest Authentication Digest authentication operates much the same way as basic authentication as is illustrated in Figure 3.2 Simplified Digest Authentication above, but with the slight modification that only hashes of the password are transported over the Internet instead of a plaintext password. The digest scheme issues challenges using a nonce value. A valid response contains a checksum of the username, password, a given nonce value, the HTTP method and the requested URI. This way, the password is never transmitted unscrambled over the Internet. [22] The basic authentication scheme is not considered a secure method of user authentication since the user name and password are passed over the network as plaintext. The authors of RFC 2617 specifically make a note that while digest authentication is better than basic authentication, it is not infallible, and much stronger methods are available with systems like Kerberos and public key based methods One-time passwords This is a special case of basic authentication where the password changes every time one authenticates to a service and none of the passwords is reusable. When doing OTP-authentication the server retains the correct passwords in a secure index so that when one authenticates only the next unused password is valid. This protects the authentication process from replay attacks in which an eavesdropper has recorded previous network traffic and discovered the username/password pair and attempts to log into the protected service using these credentials. 30

44 There are two entities in the operation of the OTP one-time password system. The generator must produce the appropriate one-time password from the user's secret pass-phrase and from information provided in the challenge from the server. The server must send a challenge, which includes the appropriate generation parameters to the generator. The one-time password must be verified, stored and needs to correspond to the sequence number. [23] This requires that the server does not contain any compromising secret information while the seed, sequence number and last used key are all public data and non-compromising given that the secure hash function used to generate the password-sequence is non-invertible. The OTP system generator passes the user's secret pass-phrase, along with a seed received from the server as part of the challenge, through multiple iterations of a secure hash function, which produces a one-time password. After each successful authentication, the number of secure hash function iterations is reduced by one, which generates a sequence of unique passwords. The server verifies the one-time password received from the generator by computing the secure hash function once, and comparing the result with the previously accepted one-time password. [23] The generator on the other hand must be reliable and secure as it contains the secret generation key with which it computes the required number of hashes to generate the correct password. A historically successful one-time password scheme is detailed in RFC 1760 "The S/KEY One-Time Password System". The One-time password system detailed in RFC2289 is the successor of S/Key. In the OTP system the password is coded as six human readable words as shown in Table 3.1 A typical one-time password sheet to encode the 64 bit long password into an more easily typed version [23] the standard dictionary for this encoding is documented in the S/Key RFC The password may also be encoded in hexadecimal as is presented in Table 3.2 Alternative hexadecimal OTP-key representations or a non-intersecting localised dictionary may be generated on a server as defined in [23] appendix B. 81: GAP LUSH BUNT LIAR ARAB BYTE 82: COW HIKE CAM SIN USES ONLY 83: TELL SWIM DIME HUG FORE FINK 84: GALE NOAH DORA BERG TUM SWAY 85: TILE VAIN BUCK KEEN SALT DAB 86: OWN FEND FLEA FOUL HOOD RAIN 87: SOFA BARD KIRK IRE JUDE DAM 88: WILD FOOL FORT CLAD GLIB PHI Table 3.1 A typical one-time password sheet 31

45 The alternative way of representing the keys in hexadecimal is shown below: b369cda8b e5cc a1b8 7c13 096b C F4 27 7B A1 CF 0x b369cda8b 0xe5cca1b87c13096b 0xc74890f4277ba1cf Table 3.2 Alternative hexadecimal OTP-key representations In the above hexadecimal representation, the first column illustrates the different acceptable forms, and the right-hand column the correct interpretation of the password. This example illustrates the requirement of total ignorance of white spaces [23]. There are a few variants of OTP like the time-based variant of SecurID from RSA Security Inc., which is a hardware token that generates new passwords every 60 seconds that are valid only for that period of time. In the SecurID scheme the token and the authentication server are clock-synchronised and seeded with the same secret start value. [24] Once the system has been activated, the stream of random numbers the token generates is identical on all similarly primed tokens. Usually, this random number is appended to a static personal secret for added security, so that the possession of the token in itself does not permit access to protected resources. 3.2 Biometric authentication Biometric authentication uses biometric data to form a biometric template of the biological feature measured by the particular biometric method. This could be the positions of curves and junctions of a fingerprint, the pigment structure of the iris or voiceprint data of a certain sentence. If the person can provide a good enough sample of the measured biometric, which closely match a previously recorded biometric template, the identity of the person authenticated is guaranteed. The best-known biometric identification method is the finger scan, while less common ones include iris scans, voiceprint, facial images and hand geometry scans. Biometrics has a very interesting future but it is not widely used today for various reasons [25]. A possible application of biometrics could be the replacement of conventional PIN-codes on smart cards with finger scans. This could occur with the integration of the card reader device and the finger scanner to build a TCB for smart card and biometric operations. 32

46 3.3 Symmetric key based cryptographic authentication All cryptographic authentication methods are so called strong authentication methods. A very secure class of methods are the multi-factor authentication systems where two or more authentication systems are used in conjunction for final authentication. Authentication can be established by using pre-established symmetric cryptographic keys and various ways of exchanging key material for a session key. These symmetric methods are described here mainly because the Kerberos system, which is described later, is based on symmetric cryptography. The ISO/IEC standardises multiple mechanisms for entity authentication. Two of the more interesting are described here. There are two major classes of cryptographic protocols based on the reliance on synchronised time between the communicating parties computers. Timestamp based protocols rely heavily on synchronised time, and subsequently succeed in creating the required security associations with fewer messages than nonsynchronised algorithms. This is a nice feature, but the price for the simplification of the protocol is obtaining reliable clock synchronisation between all communicating parties. This problem is solved by using nonces i.e. random numbers generated by the communicating parties and passed between the parties in the protocol messages. Both methods are used to enhance resistance against replay attacks by an eavesdropper replaying old messages. By tracking the freshness of issued nonces or the timestamps the communicating parties are able to deduce if a message is fresh or not ISO/IEC timestamp based unilateral authentication When performing a unilateral authentication within an environment with synchronised clocks it is possible to use the minimal authentication procedure shown below in Figure 3.3 Unilateral authentication with pre-shared key K and timestamp : 33

47 Personal Terminal Server Enter key K ab E Kab (T A,B) Figure 3.3 Unilateral authentication with pre-shared key K and timestamp The key K ab must be pre-shared and the clocks of both terminal A and server B must be synchronised for this to work. Server B can verify the validity of the authenticator by verifying the freshness of the timestamp T A and that his own identifier B is in the encrypted message. If both conditions are met, B can be certain that the message originated from A. [10, p.36] ISO/IEC nonce based mutual authentication In this example, mutual authentication can be achieved without clock synchronisation due to the use of nonces. Personal Terminal A Server B Enter key K ab N B E Kab (N A,N B,B) E Kab (N B,N A ) Figure 3.4 Mutual authentication with nonces and pre-shared key In Figure 3.4 Mutual authentication with nonces and pre-shared key the authentication process does not rely on synchronised time, but still uses preshared symmetric encryption keys. For this to work server B can check the identity of client A by first checking that the nonce N B matches that sent in phase 1, and that its identifier B is in the encrypted message. Client A establishes 34

48 server B s identity by checking that the nonces N A and N B are reversed and match those previously transmitted in phase 3. [10, p.36] 3.4 Public-key certificate based cryptographic authentication Public-Key Certificate (PKC) based authentication is a cryptographically augmented process of exchanging data encrypted with a persons public-key, which can only be decrypted by the corresponding private key of the said person. If this piece of data is returned to the sender encrypted with the sender s public key, it signifies that the original receiver had to be able to decrypt the particular piece of data before re-encryption, and therefore, has possession of the secret key. This is the general authentication type class of interest in this thesis work, because this occurs between the client and server when strong authentication happens. Here three different variations of the PKC based authentication protocols are described. These are a good representation of PKC based authentication protocols and progress from unilateral authentication with and without synchronised time to mutual authentication with and without synchronised clocks. The most interesting version of these protocols is described in X.509 mutual authentication with nonces subchapter Unilateral authentication protocols In client authentication, the client is authenticated unilaterally to the server. Figure 3.5 Simplified public-key based client authentication [25, p.384] In Figure 3.5 Simplified public-key based client authentication [25, p.384], simple client authentication procedure is depicted. The server sends a random number called a nonce-value to the client, which is called the challenge. In response to the challenge, the client encrypts E Csk (Nonce) the nonce with its secret key and returns this to the server. To verify the identity of the client the server needs to obtain the said users public key from a public directory, decrypt 35

49 the encrypted nonce D Cpk (E Csk (Nonce)) and verify the value of the decryption. The result should be the same nonce-value originally sent to the person to be authenticated. Nonce is a number that is never used more than once [10, p.36]. This process is crude and does not reflect reality in the implementation details. A more precise version is presented in the ISO/IEC Using timestamps and unilateral authentication, the ISO/IEC-way constructs a single data package in client A and sends it to server B as shown in Figure 3.6 Unilateral authentication with PKC and synchronised time : Personal Terminal A Server B Enter PIN CA (PK A ),TA,B,S -1 (TA, B) PK A Figure 3.6 Unilateral authentication with PKC and synchronised time Here client A sends his certificate C A, timestamp T A, destination identifier B and the signature of both T A and B. When server B receives this message, the validity of the certificate and its signature is verified with the given public-key. If the signature is valid, it means that the server is communicating with client A since it is the only entity in possession of the correct secret-key. [10, p.37] Mutual authentication protocols When both communicating parties wish to authenticate each other, it is called mutual authentication. This is accomplished by adding two additional steps into the one-sided processes described above forming a three-way handshake protocol ISO mutual authentication with nonces With public-key certificates, mutual authentication without clock synchronisation is obtainable for example with the ISO suggested method, as shown below in Figure 3.7 Mutual authentication with PKC s : 36

50 Personal Terminal A Server B Enter PIN N B C (PK ), N,B,S A A A -1 PK A (N, N,B) A B C (PK ),A,S B B -1 PK B (N, N,A) B A Figure 3.7 Mutual authentication with PKC s With this method server B sends a nonce N B to client A. Client A attaches his public-key certificate C A to the response message, with a new nonce N A and the destination identifier B, and digitally signs the triplet (N A, N B, B). This triplet ensures that server B can check the integrity of the message, and that A is capable of using the associated private-key. On receipt, B will check the validity of A s certificate and subsequently verify the signature S PKa (N A,N B,B) with the publickey PK A. To complete the mutual authentication server B must now send its certificate C B, the destination identifier A and the signed triplet (N B, N A, A). Client A now checks the validity of B s certificate and verifies the signature S PKb (N B,N A,A). If both signatures are valid, the communicating participants can communicate with each other, because knowledge of the secret-key is required for successful signature operations. [10, p.37] ITU-T X.509 mutual authentication with synchronised clocks In the protocol depicted in Figure 3.8 X.509 mutual authentication with synchronised time, security is based on the timestamps for validity time and forced delay detection as well as on the nonces. 37

51 Personal Terminal A Server B Enter PIN C (PK ),T, N, B, data,s A A A A -1 PK A (T, N,B, data) A A C (PK ),T, N,A, N,data',S B B B B A -1 PK B (T, N,A, N,data') B B A Figure 3.8 X.509 mutual authentication with synchronised time Client A sends a message containing its certificate C A, a timestamp T A, a nonce N A, the destination identifier B, some data like a session key and a signature over all these elements. Server B must verify the certificates validity, the timestamps freshness and the signature. If all these agree, A is authenticated to B. To authenticate to A, server B must send it its certificate C B, a timestamp T B, a nonce N B, the destination identifier A, the nonce N A, arbitrary data and a signature over these data fields. On receiving the reply, A performs the same checks as B in the previous phase. If the checks are successful, B is authenticated to A. If the data-field is used to transmit an encrypted session key E PK B ( k AB ), its validity can be confirmed by both parties by decrypting it with their respective privatekeys and validating it against the signatures. [10, p.37] X.509 mutual authentication with nonces To enable operation in an environment without trusted and synchronised time there is a three-way authentication protocol defined in the X.509 specification that relies only on nonces depicted below in Figure 3.9 X.509 mutual authentication with nonces. 38

52 Personal Terminal A Server B Enter PIN C (PK ), N,B,data,S A A A -1 PK A (N, B,data) A C (PK ), N, A, N,data',S B B B A -1 PK B (N B, A, N A,data') N,B,S B -1 PK A (N B,B) Figure 3.9 X.509 mutual authentication with nonces This differs from the timestamp-utilising version by requiring an extra step vs. not relying on timestamps. Otherwise, this operated the same as above, but instead of checking for the freshness of the timestamps, A must check that the nonce N A received in phase 2 is the same as that transmitted to B in phase 1 and similarly B must check N B in phase 3 vs. for the one transmitted in phase 2. [10, p.38] 3.5 Network authentication systems In this subchapter, the Kerberos V network authentication system is described as a prime example of a network AAA-service that enables single sign-on functionality on a wide scale. Similar systems are OSF Distributed Computing Environment DCE and Sesame, a semi-commercial European contender to Kerberos, developed as part of the EU RACE-programme. The development work was undertaken by ICL, Siemens and Bull, who are the licence holders. The Massachusetts Institute of Technology (MIT) built a scalable network authentication infrastructure in project Athena in the mid 80 s [10, p.79]. The result from this project was called Kerberos. It is currently at version 5 and it is specified in RFC The stated goals of the Kerberos system were 1) to allow a user to single signonto the network and 2) to protect the authentication information, making it more difficult for an impostor to impersonate a legit user. [10, p.80] The first published version of Kerberos was version 4, but this is now considered insecure, so only the Kerberos v5 system is described here. Kerberos is a trusted third party authentication service [7, p.566]. Notice that Kerberos does not attempt to implement the authorisation or auditing functions. 39

53 Kerberos V s most notable use today is within Windows 2000 as its domain authentication method of choice. Microsoft has added to the Kerberos V authentication protocol some Windows specific additions, and two missing heads of Cerberus authorisation and auditing ones. [10, p , p.427] Microsoft also supports the public-key initial authentication extension to Kerberos V, which is currently available as an Internet Draft from the IETF Kerberos system architecture The Kerberos system makes some assumptions about the operating environment. These are Synchronised, reliable clocks The client computer is trusted by its user The security server is always on-line The servers are stateless Because of the RSA patent only symmetric cryptography is used The time that the user client s password is available must be minimised [10, p.80-81] The Kerberos functional components are depicted below in Figure 3.10 The Kerberos general architecture [10, p.81] : Authentication Server (AS) Client Computer User Ticket Granting Server (TGS) Application Server (S) Figure 3.10 The Kerberos general architecture [10, p.81] These components are described in the following paragraphs. 40

54 The client computer Client computers are regarded insecure, because the user has full control over them. The client is usually a general-purpose computer with a Kerberos enabled OS and applications installed. [10, p.81] The authentication server The authentication servers role is to decide whether a user is who he claims to be i.e. authenticating the user. It also acts as an exchanger, exchanging weak secrets (user ID and password) to a strong secret (a cryptographic ticket). With this ticket, the user can prove his identity to the ticket granting server (TGS). [10, p.81] The ticket granting server Once the user has obtained a ticket granting ticket (TGT) from the AS, he is able to request an authenticator and a session key to a specific service S from the TGS. The TGS is able to authenticate the user based on his authenticator received with the TGT. [10, p.81-82] The application server The application server can provide a multitude of services to the client, once the client is authenticated with the application server. This is done also vice versa, if mutual authentication is requested. The messages between them can be protected cryptographically providing confidentiality and integrity. [10, p.82] Operation of the Kerberos environment The operation of the Kerberos V protocol suite is described in Figure 3.11 Kerberos V authentication steps with illustration of signal sequences. 41

55 A, TGS, RL C, N C, E K ( TC ) A User Client Computer A, E E K A K AS ( k TGS C TGS ( A, C, TGS, T, T, k, T, T, N s e C s e, TGS ) C TGS ) Authentication Server (AS) S, RL E K AS (1 ) C TGS, N (1) C, E K C TGS ( C, T (1) C ( A, C, TGS, T, T, k s e ) C TGS ) A, E E K C K TGS TGS S ( k ( A, C, TGS, T C S, T (1) s, T (1) e (1) s, N, T (1) C (1) e, S ), k C S ) Ticket Granting Server (TGS) E E K TGS k C S S ( A, C, TGS, T ( C, T (2) C, SN C S (1) s ), T (1) e, k C S ) E k C S ( T ( 2) C, SN C S ) Application Server (S) Figure 3.11 Kerberos V authentication steps When a user wants access to the application server S, he needs to authenticate to the authentication server AS with the first message exchange. In the authentication request KRB-AS-REQ (1) message, the client sends the AS its identity A, the destination identity TGS, the lifetime request RL C, a nonce N C and a pre-authenticator E Ka (T C ). The AS replies with the KRB-AS-REP (2) -message and provides the client with a session key package k C-TGS, and a ticket granting ticket for accessing the TGS. After receipt of the TGT and the client-tgs session key, the client may proceed to request a ticket for accessing server S from the TGS. This is achieved by sending the KRB-TGS-REQ (3) message with the appropriate nonce, timestamps, TGT and authenticator to the TGS. The client receives the session key for the service S in the KRB-TGS-REP (4) message. With this key, the client is able to form an authenticator for the KRB- AP-REQ (5) message with the ticket obtained previously. It may also transmit a sequence number SN C-S for use with the KRB-SAFE and KRB-PRIV messages. The application server S responds to this with an authenticator in the KRB-AP- REP (6) message. 42

56 After the conclusion of the initial authentication client C and application server S may negotiate confidentiality and integrity on the communication. This occurs by using the previously mentioned KRB-SAFE and PRIV messages. [6, p , 10, p.86-90] Pitfalls of Kerberos V There are a few shortcomings in the Kerberos V system. Some of them are listed below [10, p.89-90] Kerberos V is vulnerable to password guessing attacks Kerberos relies on client security The confidentiality and integrity of Kerberos implementations are compromised by a known attack, if both DES-CBC and DES-MAC modes are used simultaneously. Kerberos is still based on symmetric cryptography. Therefore, it does not scale well to large inter-realm environments. Kerberos does not provide non-repudiation services Kerberos lacks access control features completely Public-key cryptography extensions to Kerberos V The IETF s Kerberos working group has proposed an extension to the Kerberos V authentication service to support the use of public-key certificates in user authentication in the Internet draft draft-ietf-cat-kerberos-pk-init-15 and interrealm authentication in the Internet draft draft-ietf-cat-kerberos-pk-cross The PK Init extension PKINIT enables access to Kerberos-secured services based on initial authentication utilising public key cryptography. PKINIT utilises standard public key signature and encryption data formats within the standard Kerberos messages. The basic mechanism is as follows: The user sends an AS-REQ message to the KDC as before, except that if the user uses public key cryptography in the initial authentication step, his certificate and a signature accompany the initial request in the pre-authentication fields. Upon receipt of this request, the KDC verifies the certificate and issues a ticket granting ticket (TGT) as before, except that the encpart from the AS-REP message carrying the TGT is now encrypted utilising either a Diffie-Hellman derived key or the user's public key. This message is authenticated utilising the public key signature of the KDC. [10, p , 26] 43

57 The PK Cross-realm extension The basic operation of the PKCROSS protocol is as follows: 1. The client submits a request to the local KDC for credentials pertaining to the remote realm. This is just a typical cross realm request that may occur with or without PKCROSS. 2. The local KDC submits a PKINIT request to the remote KDC to obtain a "special" PKCROSS ticket. This is a standard PKINIT request, except that PKCROSS flag (bit 9) is set in the kdc-options field in the AS_REQ. Note that the service name in the request is for pkcross/realm@realm instead of krbtgt/realm@realm. 3. The remote KDC responds as per PKINIT, except that the ticket contains a TicketExtension, which contains policy information such as lifetime of cross realm tickets issued by KDC_l to a client. The local KDC must reflect this policy information in the credentials it forwards to the client. Call this ticket XTKT_ (l,r) to indicate that this ticket is used to authenticate the local KDC to the remote KDC. 4. The local KDC passes a ticket, TGT_(c,r) (the cross realm TGT between the client and remote KDC), to the client. This ticket contains in its TicketExtension field the ticket, XTKT_ (l,r), which contains the cross-realm key. The TGT_(c,r) ticket is encrypted using the key sealed in XTKT_(l,r). (The TicketExtension field is not encrypted.) The local KDC may optionally include another TicketExtension type that indicates the hostname and/or IP address for the remote KDC. 5. The client submits the request directly to the remote KDC, as before. 6. The remote KDC extracts XTKT_ (l,r) from the TicketExtension in order to decrypt the encrypted part of TGT_(c,r). [27] 44

58 4 SINGLE SIGN-ON ARCHITECTURE Single sign-on is a paradigm, which by utilising authentication, authorisation and auditing functions as well as protocols for dissemination of access control information, the client is provided with universal identification with a single authentication event. The fundamental problem a single sign-on solution solves is the problem of forwarding the authentication credential from one service to another in a secure manner. This should hold true even though the client is regarded entirely untrustworthy and actively attacking the security measures. This chapter attempts to clarify the different ways an S/SSO solution can be built accompanied by a discussion of different approaches to the infrastructure when operating in a pure WebSSO environment vs. a more traditional S/SSO environment of heterogeneous legacy computing resources. 4.1 Different single sign-on architectures There are various ways of accomplishing single sign-on functionality on a network of computers. The most prominent way of obtaining SSO capabilities is by utilising a client-agent-server architecture. The client is a distrusted component, capable of completing the authentication protocols and storing the access control ticket issued to it by the server if the authentication was successful. A typical client would be using a web browser acting on behalf of the user as a user-agent. The agent is situated near the protected service acting as a gatekeeper, consulting the server for authentication and authorisation decisions as well as supplying it with audit-data. The agent is a small piece of code that effectively can say yes or no to resource requests based on the authorisation information provided by the server, and forward the acceptable ones to the service and the responses back to the client. 45

59 The heart of the system is the server, which provides the back-end processing capabilities with support for different authentication methods, user databases, policy evaluation capabilities and audit logging and processing functions. The three most common ways of situating the agent will be explained shortly Native plug-in SSO agent In this model, the protected resource, i.e. the software service, is modern enough to support natively authentication method plug-ins. This enables the smooth addition of the service into the SSO infrastructure. The concept is visualised in Figure 4.1 Native plug-in architecture : Request Authentication / Send Requested Data Request Service/ Send Authenticatin Data Basic Auth Plug-In Service to be protected Pass Validated Identity to Application via internal interfaces SecurID Auth Plug-In Authentication Plug-In Interface PKI Auth Plug-In Figure 4.1 Native plug-in architecture The process that authentication and authorisation follow in this kind of architecture is described below: 1) The resource request is received by the authentication module and it is then passed to an appropriate authentication plug-in for further processing. 2) The authentication module performs its native authentication procedure and if it finds a valid identity match, the plug-in passes the extracted credentials to the service with a valid response, indicating the status of the authentication process. 3) After this, the application trusts the plug-ins evaluation ability of authentication, and begins serving the requests made by the client. If the used plug-in is a SSO enabled one, it will consult a policy database for the authenticated clients access rights, and act as a policy enforcer between the protected service and the client. It also has to be able to propagate the authorisation credentials from one service to another in order to enable SSO functionality. [28] 46

60 What distinguishes this from the next method is the involved binding with a specified application by integrating directly into the applications internal authentication and authorisation logic and API as a plug-in Helper application agent This differs from the previous agent with regards to the location of the agent in the system. In this instance, the agent is situated in the same physical computer, but it is not as indigenous to the application as a plug-in. It has to take over the applications data connection paths and redirect them through itself to be able to intercept the data connections before they reach the application. After interception, the agent operates in much the same way as the plug-in agent does, with the exception of how the authentication data is transmitted to the application. This difference is depicted below in Figure 4.2 External agent architecture : Figure 4.2 External agent architecture The most notable difference is the requirement for the ability to pass authentication information to the application. This approach is usually used with applications that are too old to support plug-ins, which are hosted on a common enough OS platform that agents are available for it. Usually, the external authentication data passing mechanism employed uses the native basic authentication facility with the agent on behalf of the client. [29] Reverse proxy architecture With this method shown in Figure 4.3 Reverse proxy architecture the functionality of the agent is situated in an external computer that routes traffic from the public network to the private network, which is shared between the proxy and the service. The logic of this model differs only slightly from the above external agent model. Nevertheless, it has quite a different implementation structure. [30] 47

61 Figure 4.3 Reverse proxy architecture This solution is required if the service is not able to use either plug-ins or there does not exist an agent that will run on the OS platform of the service. In this case, the agent is running in its own computing environment and masquerading as a server to the client and as a client to the service only communicating with its peers via the networks. Here the public side of the proxy-agent is what is seen to the outside world and the real services are mapped to its virtual directory hierarchy. 4.2 Reduced sign-on architectures Reduced sign-on means that an RSO -application controls key management on behalf of the user and uses them when prompted by the various services the client wishes to access. This differs only slightly from single sign-on but the difference is fundamental. [31] The fundamental difference between these two is that in a pure single sign-on model the chosen authentication method is used for all services, whereas in RSO, the agent residing in the clients computer may know of multiple different authentication methods and apply these when needed. To clarify this distinction Figure 4.4 Reduced sign-on architecture is provided below: 48

62 Request Authentication / Send Requested Data Service to be protected Use Stored Basic Credentials Request Service/ Send Authenticatin Data Basic Auth Plug-In Authentication Plug-In Interface Pass Validated Identity to Application via internal interfaces RSO Agent Use Stored SecurID Credentials Request Authentication / Send Requested Data Request Service/ Send Authenticatin Data SecurID Auth Service to be protected Authentication Plug-In Interface Pass Validated Identity to Application via internal interfaces Use Stored SSO Credentials Request Authentication / Send Requested Data Service to be protected Request Service/ Send Authenticatin Data PKI Auth Authentication Plug-In Interface Pass Validated Identity to Application via internal interfaces Figure 4.4 Reduced sign-on architecture The location of the RSO agent is in the client not the service. This approach is quite clumsy, as every end-system has to have explicit support in the client agent to be able to utilise this architecture. In this example, using a different authentication method for every system emphasises the differentiation to proper SSO solutions. The user will authenticate himself to the RSO agent once and the RSO agent authenticates him to all subsequently accessed protected resources in the RSO domain. In an SSO environment, the user authenticates to a central authority and receives a universal (in the SSO domain) credential of identity that all the services are able to check. 4.3 Single sign-on on the web The web environment is a natural platform for native plug-in agents since most modern web-servers support pluggable authentication modules and run on a few OS platforms that are generally well supported. In addition, the web paradigm provides native support for convenient identity ticket transfer from one service to another via the cookie mechanism. 49

63 4.3.1 Credential passing methods When the user requests a www-page via his browser, he in effect makes an HTTP-request for the resource defined in his browsers URL. When this request is received at the www-server, it begins a process described below. If the server is not single sign-on enabled, the server just sends the requested data back to the requestor when the request reaches the server data port. There might be some active access controls, which may tell the server whether the requestor is permitted to access the requested data based on identity, IP-address or hostname. Apart from this, the server has no way of knowing whether to send the requested data or to skip re-identification, if the user has previously been authenticated. Browser Resource Request Agent Agent/Server #1 Authentication Request CookieGeneration Personal Terminal Authentication Response Set Authorisation Cookie Resource Response Enter authentication information Browser Resource Request Resource Request Cookie Request Agent Authentication and Authorisation Database CookieValidation Cookie Response Renew Authorisation Cookie Resource Response Agent/Server #2 Resource Request Figure 4.5 Cookie handling in the WebSSO environment With single sign-on capabilities in the server, the user is authenticated after his initial data request and a single sign-on ticket is either issued to the users browser in the form of a cookie or encoded in the URLs of the html-document send to him per his initial request. This is clarified in Figure 4.5 Cookie handling in the WebSSO environment. 50

64 This ticket usually contains an encrypted certificate of validity that the wwwserver or the SSO agent software on that server checks every time the user makes additional requests for data from the server. With the cookie mechanism, any server in the same cookie-domain can always check the content of any cookie previously issued by any one of the other servers, automatically re-authenticating the user for every subsequent request without user intervention. With URL-embedded tickets, the cryptographic ticket is embedded in every hyperlink from the initial, and all subsequent pages, so the ticket is passed to the server as part of the data request. This is not as flexible as the cookie-based method because it only permits the user a single sign-on to those resources reachable via the encoded URLs on the page. You cannot do large-scale SSO with these because if you visit another site outside the SSO realm and return to another resource in the realm the authentication information is lost. Either these tickets have a certain predefined period of validity after which time the user is required to re-authenticate, or the server may automatically refresh the ticket by reissuing the cookie or the URL encoding Simple WebSSO scenario The authentication method can vary from one implementation to another, and it may be anything from simple user-id/password combinations to retinal scan based biometric authentication information. The only limit is imagination. For simplicity s sake, only two protected servers are used in the example described in Figure 4.6 Illustration of multi-host SSO in the web environment. Web server and SSO agent Authentication and authorisation queries and responces Client Initial request and authentication trafic Additional requests and responces Single sign-on to second server and authentication check Policy Server Policy and authorisation data requests Policy and user database Authentication and authorisation queries and responces Web server and SSO agent Figure 4.6 Illustration of multi-host SSO in the web environment When a client requests access to a protected resource, his authentication status is first checked, and if it is found lacking, it is redirected to the authentication service by the SSO agent. When the authentication procedure is successfully 51

65 completed, the SSO service issues an access ticket, which is relayed to the client by the SSO agent and the original request is only served, if the clients authorisation is sufficient. All subsequent access requests are served based on the initial status- and authorisation check. Usually, the ticket is valid for a specified period and when it expires, the client must re-authenticate. This is not normally a problem as the ticket is renewed automatically if the session is actively in use, and therefore, it does not visibly expire while actively browsing. The access policy is maintained by the policy service, and usually, the policy check results are cached at the agent temporarily to lighten the load of the policy server. With the single sign-on framework acting in the background, this scheme can easily be extended to cover hundreds of services by installing these agents on every www-server that is to be protected centrally Rejection points There are two obvious places of rejection, with authentication and authorisation. One must understand that authentication and authorisation are two entirely different things. One may be a legal user of one part of a www-service, while at the same time be unauthorised to use another. All S/SSO products that were tested implement authentication and authorisation as two separate services. 4.4 Generalised single sign-on model In the web environment, SSO is easier to implement than in most other environments because the web paradigm includes the concept of cookies, which act as the perfect ticket issuance/storage mechanism. For a more general implementation of SSO, a complete array of plug-ins and helper applications must be developed for every platform and application to bring these non-native services to existing applications. Some products on the market implement SSO capabilities on various systems like IBM Global Sign-On and RSA Keon Desktop. These are unfortunately very dependent on an array of natively supported applications, and therefore are not very flexible to use. 52

66 One of the best-integrated SSO-like authentication mechanisms is the Microsoft Windows 2000 domain authentication mechanism with which they use Kerberos V as the basis for network authentication with rudimentary support for PKI enabled applications. It is unfortunate that the Windows 2000 model is bound too tightly to this operating system for wider acceptance in a heterogeneous computing environment. [10, p ] 53

67 5 RISK-ANALYSIS BASED REQUIREMENT SPECIFICATION In this chapter, the requirements for an S/SSO infrastructure are developed by the author and Elisa Research Centre/IT Security R&D team. The Research Centre s opinions are used for guidance by the Elisa s Data Administration Division in their decision-making and evaluation process. This requirement specification is built from a risk-analysis perspective to provide the reader with a greater understanding of the risks associated with a requirement item. The deployment environment of this infrastructure is a multi-site operation with a completely heterogeneous client-server environment in the web-arena. Because of this, some requirements become more crucial than others. Examples of these are both geographical and logical decentralisation, incremental scalability and requirements enforced by law on telecom operators such as the obligation of diligence and the Population Registration Act. Because this thesis concentrates on the security of the SSO products themselves, it is natural to point out here that even the best software security cannot compensate for non-existent physical security measures. Therefore, I hope the reader appreciates that something as critical as a centralised authentication and authorisation system must be physically protected with at least the same care as other critical systems like payroll computers and e-commerce machinery. In this thesis, proper location security is assumed. A proposal has been discussed by the EU parliament to ban or at least limit the use of cookies [32], which might impose severe limitations on the usability of current S/SSO solutions. In anticipation of this legislation, additional requirements for alternative identity dissemination methods were introduced. 54

68 5.1 Raw requirements The raw requirement list is presented in the following table and the risks related to each requirement are separately discussed in the following subchapters. Raw requirement specification Encrypted communication paths Secure key management Cryptographic access tickets Alternative method of ticketing Pluggable authentication method support Strong authentication support Transaction non-repudiation Fine grained access policy enforcement Transaction atomicity Component redundancy Disaster recovery Incremental scalability Load balancing features Multi-platform availability Centralised management framework integration Delegated administration External application server support Future support for global authenticators Remote administration Graphical UI for administration Database locations and supported formats Table 5.1 Raw requirement specification These requirements cover the most general requirements for a networked authentication and authorisation system. A much more complex model could easily be compiled but for this task, these requirements were sufficient. 5.2 Confidentiality and integrity This subchapter discusses the justification of each raw requirement shown above which is related to confidentiality and integrity of data transferred over the network or stored on hosts. 55

69 5.2.1 Encrypted communication paths Risk: An attacker is able to forge, modify or inject false information into the AAA-process while the data is in transit. Justification: This becomes a crucial point of failure if the AAA infrastructure needs to use insecure communications over the Internet to operate. Solution: All communication paths between the S/SSO systems components and between the clients and the S/SSO system must be encrypted using methods that both guarantee confidentiality and integrity Secure key management Risk: An attacker is able to gain access credentials because of insecure key handling in the SSO framework. Justification: If the encryption keys are compromised, it will ruin the security of the entire platform. Solution: All key handling should be done using open and proven key management methods Cryptographic access tickets Risk: An attacker is able to forge his access ticket in his cookie store to reflect elevated privileges. Justification: All data that is stored on a client s computer should be regarded as having originated from an untrustworthy source and being subject to limitless tampering on the behalf of the client. Solution: All cookies submitted to the client for S/SSO credential passing must be encrypted with strong algorithms and a key known only to the S/SSO system. Preferably, this key should be randomly selected for every session to minimise the risk of brute force and dictionary attacks on the key Alternative method of ticketing Risk: The EU legislation bans the use of cookies 56

70 Justification: This legislation is currently a proposal [32] to ban the use of secret cookies in the EU parliament for inclusion into European law. If the Finnish lawmakers implement this act in an inappropriate manner, cookies may be banned altogether. Solution: An alternative method for credential passing is required Pluggable authentication method support Risk: A secure authentication method today might become volatile in the future. Justification: If this risk occurs, it should be easy to switch to another secure authentication method without affecting the entire infrastructure or disrupting the service. It is an expensive process to re-customise the applications using this infrastructure if the authentication API is not general enough to support pluggable back-end authentication methods. Solution: Dynamic, pluggable authentication methods in the back-end system as well as open API s for custom authentication method implementation should be available from the manufacturer Strong authentication support Risk: An attacker is able to penetrate the authentication methods either by brute force, dictionary attacks or other penetration methods. Justification: If the authentication method is susceptible to attack, forgery or impersonation, the whole infrastructure becomes useless since it relies on the imperviousness of the underlying authentication to provide precise identity information. Solution: The product must support strong two-factor authentication methods, which will foil most conventional attacks on authentication methods like guessing passwords, social engineering, brute force and dictionary attacks Transaction non-repudiation Risk: Without non-repudiation, a rogue customer can claim not to have conducted the contested transaction. 57

71 Justification: When implementing an S/SSO infrastructure like this, it is likely to have commercial services rely on the identification framework provided. When money is involved in the services, fraudulent usage will always follow. Solution: This risk can be mitigated by implementing compulsory nonrepudiation services into these kinds of services to protect both the S/SSO and the commercial service provider Fine grained access policy enforcement Risk: A valid user is able to gain unauthorised access to data. Justification: Too general object controls may result in over privileging users that need to access some information under control, but not all information the access privilege grants. Solution: It requires fine-grained access policy enforcement in order to build just the right sized access groups with a least privilege -approach. A sufficiently granular approach could reach down to the level of individual objects e.g. files or pictures, but not necessarily all the way down to paragraph or method levels. 5.3 Availability This subchapter discusses the justification of each raw requirement above which is related to availability features of the authentication framework. In this instance, good availability should be considered to be in the % annual reliability window Transaction atomicity Risk: 1) An attacker is capable of disrupting an AAA-transaction and forcing the system into an undefined state. 2) If the S/SSO infrastructure crashes for any other reason and a partly committed change to its configuration is stored in the database resulting in immediate crash upon restart. Justification: By being able to drive the system into an undefined state, it might be possible to exploit the resulting state for access permission elevation or other misuse of the system. Additionally, if the system fails for any reason atomic transactions guarantee that the databases are always in a well-defined state. Solution: All database transactions must be atomic. 58

72 5.3.2 Component redundancy Risk: A component failure will result in denial of service. Justification: The failure of the S/SSO system will cause system wide denial of service to all users of the system. If a single component failure can render the entire system useless, it must be possible to add redundancy to this component to avoid the huge risk involved in its failure. In comparison, it is cheap to build redundant computers to having all corporate operations halted because of the resulting denial of service. Solution: Components that are in the high-risk area of functionality must be capable of operating in a clustered fail-over environment. With multiple concurrent systems with fail-over facilities, the risk of complete failure of that subsystem is greatly reduced Disaster recovery Risk: A computing facility is attacked by a natural catastrophe or human caused incident rendering it unavailable. Justification: If the whole system is located in the same physical facility, a risk exists that the entire platform will be wiped out in one great accident, resulting in denial of service. Elisa s Business and Disaster Recovery Plan requires at least a Hot Site -backup system and strongly suggests having fully redundant systems in geographically separate locations. Solution: It should be possible to divide the infrastructure into at least two different physical locations for added security and availability Incremental scalability Risk: The number of transactions outgrows the systems capabilities. This could mean in practice that a single S/SSO infrastructure must be able to handle at least the population of Finland ~ clients in expanded configurations. Justification: If the S/SSO system is a commercial success, the user base might begin to grow at an unexpected rate, possibly resulting in partial denial of service, because the server back-end simply cannot process the numerous transactions. Solution: The product must have a well-defined, incremental growth path to extreme user bases and transaction counts to satisfy the requirements for a large 59

73 user base. Incremental scalability means that the S/SSO platform must be capable of accepting new modules to the existing framework without disrupting the current services on-line Load balancing features Risk: The infrastructure is unable to handle all requests on time. Justification: When the load on the servers grows, it is more economical to have all servers operate in a load-balancing configuration instead of having dedicated backup systems waiting idle for the operational system to fail. This way the best of both worlds is realised in having on-line backup systems available and at the same time optimising the load distribution of the infrastructure. Solution: The fail-over nodes must be able to operate in a load-balancing configuration as well as the fail-over nodes themselves Multi-platform availability Risk: The solutions platform (OS or hardware) becomes obsolete or goes out of business and leaves Elisa Communications without support for future growth and services. Justification: When tied to a single platform it is possible that a bankrupt vendor could harm the overall operation of the production system. In another scenario, there might be substantial cost savings available if there are available alternatives like the free operating systems (Linux and FreeBSD vs. Microsoft Windows and IBM AIX) or cheaper hardware platforms (Intel vs. Sun). Solution: The product is required to support these cheaper and more available platforms before accepting it into production. In addition, the roadmaps for these future product lines should be checked to ensure later supportability. 5.4 Accountability and audit This subchapter discusses the justification of each raw requirement above which is related to data collection mechanisms, which provide adequate data for both internal and external audit purposes. 60

74 5.4.1 Centralised management framework integration Risk: 1) The product uses its own administration tools and user databases and consequently goes out of sync with the main user databases and policies. In addition, additional administration costs are generated by requiring multiple administrative staff. 2) If support for the required management infrastructure is absent, it will result in high costs for customisation work needed to utilise the framework. 3) Becoming part of a centralised management framework also brings unexpected security considerations into the S/SSO systems overall security model, because the framework must also be audited for possible flaws and misinteractions with the S/SSO infrastructure. Justification: It is unnecessarily complicated to keep two concurrent infrastructures in synchronisation with each other s users, policies and objects. This might result in needless delays in the policy or user data propagation to both systems if they do not share databases with each other. This also enables the use of centralised audit-facilities in the management framework. Solution: There should be a plug-in to the centralised management framework for administration of the S/SSO infrastructure with its user- and policy management tools. In addition, the interaction of these two components needs to be audited and the security of the management framework should be considered in conjunction to the S/SSO security model evaluation Delegated administration Risk: The administrator has too much power and exploits that power maliciously. Justification: It has been discovered over the years that too much power in too few hands can wreak havoc on the most secure systems. This has been the case in the UNIX and Windows operating systems and has resulted in the ideal of delegated administrative privileges, where no single person has complete power over the system. This is also called duty separation i.e. the administrator who can modify account information cannot modify the audit trail of those modifications and vice versa. It can also provide new business opportunities by enabling complex owner-beareroperator-user relationships and role separation. This affords possibilities of providing the platform as an ASP-solution to customers. 61

75 Solution: Require delegated administration capabilities to be supported by the products. The minimal delegation granularity should be at the user role level, but a more granular approach would be appreciated. 5.5 Other features This subchapter discusses the justification of each raw requirement shown above, which is related to things, which do not fit into any of the preceding categories External application server support Risk: The solution is too limited, since it can only be used to interoperate with web servers, and not the back-end application servers. Justification: If the solution does not include methods to pass the authentication information to the back-end processing servers, it will limit the application programmer s possibilities. In addition, it might trigger unexpected failures in the back-end applications by interfering in their communication with the web servers. Solution: Require native support for at least IBM WebSphere, Bea WebLogic, and Allaire ColdFusion Future support for global authenticators Risk: Ubiquitous mobile computing requires a network-based authentication method and it will be based on certificates on SWIM-cards. As the S/SSOinfrastructure is going to be used as this authentication service provider, it has to support such duty separation between the mobile handset and the network. Justification: As the telecommunication market converges with mobile and PDA markets, this will bring immense pressure to provide global authentication services into every personal communicator device. Solution: Support plans for both Microsoft Passport and Liberty Alliance global authentication framework integration should be made available. Plans for how the S/SSO product will position itself in this global market as a service provider himself of as a proxy for these global players have to be evaluated. 62

76 5.5.3 Remote administrations Risk: The system needs attention from the administrator and he is unavailable to see to it locally. Justification: Usually, the daily administration does not require console activity. Simple parameter changes should be doable remotely with suitable tools, because it is uneconomical to dispatch administrators to every remote system console. When a proper remote management system is in place, a few administrators can handle the entire systems administrative tasks from a centralised location. Solution: The product itself provides a user interface that can be securely accessed from a remote location e.g. a Java-based administration console or a web front-end to the administration software Graphical UI for administration Risk: The administrator does not understand the logic of the UI provided to him. Justification: Many software products fail to provide readability, clearness and usability of the UI. If the UI is too difficult to learn, this usually results in a reluctance to perform the necessary administration tasks on time. Solution: Make sure the UI is reasonably simple and straightforward for the administration personnel to understand and use. If the UI is too difficult to use, collaboration with the solution provider is needed to make it more suitable for the administrators Database locations and supported formats Risk: The product stores data in a strange format that cannot be understood by any other system. Justification: If a product uses a proprietary database for storing its critical information, it could complicate or even prevent the backup process and sharing of the data. Solution: Require that the system either uses open database access methods like LDAP or ODBC or has good import/export tools available for automated database synchronisation between different systems in a common format. 63

77 5.6 Summary of requirements These requirements are mainly based on current issues, the experiences of the author and his knowledge of general systems failure and security aspects. The grouping follows the traditional computer security categorisation into confidentiality/integrity, availability, accountability/audit and miscellaneous features. This requirement list may need to be augmented after the laboratory benchmarking to test the requirements in practice. The most critical feature classes in this list are firstly the confidentiality/integrity requirements, because without both, the entire operation is in danger. Secondly, the availability features as they dictate how trustworthy a service is. The other requirement classes are less sensitive, because the basic operation is secured by the above requirements. 64

78 6 COMMERCIAL SINGLE SIGN-ON PRODUCT SURVEY In this subchapter, many single sign-on products currently available on the market are enumerated, and the way in which they implement capabilities similar to single sign-on will be briefly commented on. This part of the study is based entirely on marketing data from the vendors web sites, so no guarantees as to the accuracy of the claims can be given by the author. These products were chosen from the results of an extensive web search originally conducted in December 2000, and updated in January More than half of the original products have been withdrawn from the market or have since been acquired by a rival company. Therefore, only ten currently available products are introduced in random order below. 6.1 Computer Associates International: etrust Single Sign- On This single sign-on module was previously known as the Unicenter TNG Single Sign-On option. It provides single sign-on functionality to both web and legacy environments, and is part of the etrust family of security management products from CAI. [33] 6.2 CyberSafe: TrustBroker CyberSafe s TrustBroker is a legacy single sign-on product that supports Windows NT/2000 and UNIX login functionalities. It includes support for basic, Kerberos and PKI-based authentication methods and it is expandable via GSS- API. UNIX systems supported by the product include Solaris, HP-UX, Tru64, AIX and MVS. Web single sign-on functionality could be implemented if it is customised with the supplied WebSDK. [34] 65

79 6.3 DataLynx: Guardian Guardian is a reduced sign-on solution, which provides password synchronisation across multiple operating systems and applications. The main supported platforms are UNIX and Windows NT. [35] 6.4 Entrust: GetAccess GetAccess is a single sign-on solution for the web arena. It provides single signon support with both basic and strong authentication for web clients. It is available for Windows NT/2000 and Solaris on the servers and any web browser for the client. This product was previously known as EnCommerce Get Access. [36] 6.5 Evidian: AccessMaster SSO AccessMaster SSO is a reduced sign-on solution which stores and controls the multiple passwords on behalf of the user. The user is automatically authenticated to all systems he accesses by the RSO agent. It supports basic and smart card authentication to the client desktop agent. It supports Windows 9x/NT/2000, Solaris, AIX and Linux login automation. It was originally know as BullSoft AccessMaster. [37] 6.6 Tivoli: SecureWay Policy Director Policy Director is a reverse proxy type web single sign-on solution. It provides virtual directory mapping of resources at the proxy level, and enables centralised user management via either its own management console or integration with Tivoli User Manager of the Tivoli Framework. Supported authentication methods are basic, DCE, token and smart card authentication. It is supported on Windows NT/2000, Solaris and AIX platforms. A standard web browser is needed for the client environment. [38] 6.7 Netegrity: SiteMinder SiteMinder is a web single sign-on solution, which provides authentication, and authorisation services to web and application servers. Supported authentication methods include basic, form-, token-based and smart card authentication. It is supported on Windows NT/2000 and Solaris. Any cookie enabled web browser is required as the client environment. [39] 66

80 6.8 RSA: ClearTrust ClearTrust is a web single sign-on solution, which was previously known as Securant ClearTrust. It is an agent-server model based access control solution, and supports basic, token and smart card authentication. It is supported on Windows NT/2000, HP-UX, Solaris, AIX and Tru64 platforms. [40] 6.9 Proginet: SecurPass Sync SecurPass is a reduced sign-on solution for password synchronisation between Windows NT/2000 and UNIX environments. It supports Windows 9x/NT/2000, Solaris, HP-UX, AIX, VMS, OS/390, AS/400 and NetWare. [41] 6.10 Unisys: Single Point Security SPS is more of a toolkit approach to single sign-on, but it still provides both legacy and web single sign-on capabilities. It supports basic, token and smart card authentication with integral support for a wealth of different user databases. SPS is available on Windows NT/2000, VMS, Netware, Tandem Himalaya, Tru64, AIX, HP-UX and Solaris. [42] 6.11 Feature summary of surveyed products In the following Table 6.1 Supported features in surveyed products, the above feature descriptions are summarised in tabular form for easier feature comparison. Supported Single Signon Method Supported Authentication Methods Supported Operating Systems Products RSO Legacy SSO Web SSO Basic Auth Token Auth Smart Card Auth Windows NT/2000 Solaris Other Unix Netware etrust SSO X X X X X X X X TrustBroker X X X X X X X X Guardian X X X X X X GetAccess X X X X X X Access Master X X X X X X 67

81 Supported Single Sign-on Method Supported Authentication Methods Supported Operating Systems Products RSO Legacy SSO Web SSO Basic Auth Token Auth Smart Card Auth Windows NT/2000 Solaris Other Unix Netware Policy Director X X X X X X X SiteMinder X X X X X X X ClearTrust X X X X X X X SecurPass Sync X X X X X X SPS X X X X X X X X X Table 6.1 Supported features in surveyed products From this table you will notice that there are only a few full featured products in this line-up. The most interesting products concerning WebSSO and smart card support are Policy Director, ClearTrust and SiteMinder. In addition, very feature rich products like etrust SSO, TrustBroker and SPS are listed, but they are either prohibitively expensive or much too complex for the current needs of a web single sign-on and access control environment. The other products are of no interest in this thesis, because they only support a subset of the mandatory features identified previously Selection process of the products to be tested Based on the above discussion of interesting products and their claimed features, several vendors were contacted for product presentations, talks and further clarification of the claimed functionalities each product advertises in its marketing materials. After a thorough evaluation of these products based on all collected data and vendor impressions, three products were chosen for actual laboratory evaluations. These were RSA ClearTrust, Netegrity SiteMinder and IBM Policy Director. From the products tested, the winner is evaluated below in chapter 7 Evaluation Of The Selected Product. The other two were lacking in either their certificate support or the architecture. ClearTrust claimed to support certificates while actually using them only as textual containers for usernames and PolicyDirector is tied to the reverse proxy architecture so it would not be versatile enough for our application. 68

82 7 EVALUATION OF THE SELECTED PRODUCT After evaluating the three products mentioned above Netegrity SiteMinder was chosen as the example evaluation product because of its merits. Its architecture, user interface and operation are described in detail, and evaluated as an example of an S/SSO product according to the criteria defined in chapter Evaluation background The evaluated service platform is to be deployed into the Elisa Research Centre s extranet setting with both internal and third party clients accessing the same information. It is therefore crucial that the sites access control and policies are of the highest quality and that there is clear role separation of administrative duties. The basis of this evaluation lies between the requirements of open access to extranet clients, and information publication on time to these external clients. It needs to be possible to store public, confidential and secret documents on the extranet, because some of the external partners are more involved in the projects. Some partners have cursory access to old results, while others are active participants in research projects. There is a clear need to delegate administration, because there are many projects running concurrently and each project leader needs to be able to add to and remove users from his project access group. 7.2 Netegrity SiteMinder 4.51 Netegrity SiteMinder (SM) was tested in the Research Centre s laboratory. The main platform for testing was the Solaris platform running on Sun hardware. SiteMinder is the most versatile product with regard to architectural possibilities that range from fully distributed to reverse proxy operation. Typically, SM operates in a native-agent mode with clustered policy services providing fail-over capabilities. 69

83 In this sub-chapter, SiteMinder s features, components, architecture and operations are described. In later sub-chapters, the administration application is briefly explained and the test bench setup is discussed. Finally, SiteMinder is evaluated against the requirement specification introduced in chapter 5, and problems encountered during the tests are described in detail Supported platforms Netegrity SiteMinder is supported on the following server platforms i.e. the policy server component can be run on Windows NT/2000 or Solaris. The web agent platforms include [39]: MS Internet Information Server on Windows NT/2000 Netscape Server on Windows NT/2000, Solaris, HP-UX and AIX Apache on Linux, Solaris and HP-UX Domino on Solaris and HP-UX IBM HTTP on AIX Supported user directories include [39]: iplanet Directory Server Oracle Directory Server Microsoft Active Directory Novell NDS edirectory IBM SecureWay Directory Siemens DirX Critical Path MS SQL Server Oracle Windows NT Domain Database SiteMinders functional components SiteMinder consists of a few major components. These are The policy server (authentication, authorisation, audit, administration) The policy store (directory) The user database (directory) Web- and affiliate agents (web- and application servers) External authentication services (custom authentication schemes) 70

84 External Authentication Services Administration Server Audit Server Audit Database User Directory Authentication Server Authorisation Server Policy Store Web Agent Web Agent Web Agent Web Server Web Server Web Server Figure 7.1 Netegrity SiteMinder components and interactions The policy server component provides four distinct services to the SiteMinder application agents: authentication, authorisation, audit and administration services. All of these services are provided by separate daemons and at least authentication and authorisation need to be present for SM to be operational. The relationships and components are shown in Figure 7.1 Netegrity SiteMinder components and interactions above. In addition to these core services, SiteMinder requires two directory repositories the user data and policy data repositories. These are usually obtained by using an LDAP server with suitable schemas installed to support the SiteMinder structures. It is also possible to use databases for the user- and policy stores like Oracle or MS SQL Server. With both the core services and databases on-line, the agents can be distributed to all services that require protection. The standard agents support all of the aforementioned web server and operating system combinations. It is also possible to configure an Apache web server running on Solaris to act as a reverse proxy for the protection of such services that are not running on supported platforms. 71

85 7.2.3 SiteMinder s architecture SiteMinder s architecture is quite simple and powerful. The major components are depicted below in Figure 7.2 The SiteMinder architecture overview are briefly explained below: External Authentication Logic Web Server and Agent Policy Data Policy Store User S/SSO Web Server and Agent Authentication and Authorisation User Data Web Server and Agent Policy Server Cluster User Directories Web Server and Agent Figure 7.2 The SiteMinder architecture overview SiteMinder s architecture consists of few central components - the policy server, the user- and policy directories, external authentication logics and the agents. Its power lies in the extensive use of external directories and a powerful policy description language. When a user tries to access the protected resource on a web server, he actually communicates with the SiteMinder web agent. The web agent takes care of all authentication and authorisation procedures on behalf of the web server and application servers. If the resource requires authentication the web agent prompts the user with the desired authentication dialogs and proceeds with the authentication process with the policy server. If an application server or the web server requires knowledge of the user, this can be forwarded by using HTTPheaders that the web agent includes in the requests it forwards to the protected service Load balancing and fail-over support Load balancing distributes data traffic across many systems to avoid overburdening a single system. Load balancing provides faster and more efficient access to resources, such as policies or user directories. Fail-over is a redundancy mode that allows an administrator to specify a primary and a set of backup systems. When the primary system fails, requests are transferred to the backup 72

86 systems until the primary recovers. SiteMinder supports load balancing and failover between the following: - Web Agents and Policy Servers - Policy Servers and LDAP user directories - Policy Servers and ODBC user databases (fail-over only) You can select the load-balancing operation mode to distribute user requests directed from the Web Agents to multiple Policy Servers and from the Policy Server to replicated LDAP user directories. [43, p.63] Operation description SiteMinder s operation is quite complex. It relies on multiple components, which operate in concert to provide authentication of the user and authorisation of his requested actions. In the following paragraphs, the operation of SiteMinder is explained with the help of a hypothetical login event. Resource protection First, the user attempts to access a protected resource by specifying the application s URL. The Web Agent will intercept this request at the server, and determine from its locally cached copy of the policy database whether this resource is being protected by SiteMinder [44]. If not, then it will exit and the Web Server will process the request. Otherwise, it will proceed with the authentication request process described below. Authentication If SiteMinder is protecting the resource, the Policy Server will determine which form of authentication is required based on its policy database and the associated security levels of the requested URI. SiteMinder supports a wide range of authentication methods including passwords, certificates and tokens, but also a combination of these methods. [44] The Web Agent will send a request to the user's browser, and it will return the user's credentials. Typically, this is a username/password, but it could also be a certificate and a token card PIN. The Policy Server then passes this information to the directory for authentication. [44] With certificates, this involves the checking of the integrity of the certificate and once convinced of its integrity and trustworthiness, the extraction of the specified mapping-field from the certificate and comparing this with the directory s corresponding entry. If the user failed to authenticate, then custom pages or actions can be taken, such as a personalised error page. If the user successfully authenticated to the Policy Server, then a strongly encrypted cookie is created and stored in the user's browser. This cookie does not contain any sensitive information like a password. 73

87 Instead, it contains the user's full directory name, and a number of timestamps and other information. Once a user has successfully authenticated to SiteMinder, this cookie can be used later to allow single sign-on across all the applications on the Web site. [44] If cookies are not supported by the browser, session tracking can be obtained by following the SSL-session ID s, but global single sign-on functionality is lost. Authorisation Once the user has been authenticated, SiteMinder must next determine if they should be granted access to this specific resource. The Policy Server then looks up all the policies that are related to the requested resource. The Policy Server consults the directory, and determines whether the user is a member of any of the groups associated with these policies. If the user is not authorised for this resource, then custom error pages can be created and presented to the user. If the authorisation is successful, then the user will be granted access to the application. [44] Personalisation When the application is invoked, SiteMinder passes information concerning this user directly to the application in the form of header variables. This information often contains user attributes from the directory or it could be dynamic data from various data sources. [44] PKI support SiteMinder has very good support for PKI and X.509v3 certificates. It supports all certificates issued by the major commercial certificate authorities, and revocation list processing. Figure 7.3 SiteMinder X.509 client authentication process explains the operation of SiteMinder in the client-certificate authentication process. 74

88 Web Server Web Agent Azn_Redirect(Cert,URL) Azn_Info(UID,URL) Policy Server Web Agent/ SCC Azn_Request(DN, URL) HTTP_Request(URL) SSL Client Authentication(Cert) Figure 7.3 SiteMinder X.509 client authentication process When a user authenticates using an X.509v3 certificate, the SiteMinder Web Agent forwards the connection to the SSL Credential Collector after the X.509v3 client authentication has successfully been completed. SCC then extracts the necessary user information from the certificate, such as a user s distinguished name (DN) and the certificate issuer s DN for further processing. The Web Agent/SCC passes this information to the Policy Server. The Policy Server verifies that the user is listed in the appropriate user directory, and then authenticates the user. [45, p. 230] After verifying the user s identity and validity, the Policy Server authorises the user access to the requested resources. SiteMinder also supports certificate revocation list (CRL) processing provided by most PKI vendors. Certificate revocation checking ensures that the certificates in use have not been invalidated by the owner. If a certificate expires, the PKI system does not accept it, which is critical for secure transactions. [43, p59] 7.3 The SiteMinder test bench The general test setup built by the author in Elisa s Research Centre laboratory was constructed as illustrated in Figure 7.4 SiteMinder test setup below: 75

89 IIS4 + Web Agent Local Policy Store FINEID Directory IIS5 + Web Agent IIS5 + Web Agent SM Policy Server Portugal Telecom Directory Netscape HTTPd + Web Agent Elisa Research Directory Figure 7.4 SiteMinder test setup Elisa Research Centre had as figure 7.4 describes one Policy Server running on Solaris 8, which was accompanied by the Netscape web server. Logically these two are separate, and therefore they are separated into two different entities in the picture. The Policy Server had its local policy store in a flat file database, and all entitlement information was stored in this database. There were multiple web servers participating in the test and they were: sm-iis.rc.elisa.fi running Windows NT 4.0 Server and Internet Information Server 4.0 parsec.rc.elisa.fi running Windows 2000 Server and Internet Information Server 5.0 pt-iaa.pki.aveiro-digital.org running Windows 2000 Server and Internet Information Server 5.0 in Portugal netra3.rc.elisa.fi as the Netscape/iPlanet HTTP-server running on Solaris 8 on the same Sun as the Policy Server. The directories used for this test were the governmental Finnish Electronic Identity (FINEID) public directory, Elisa Research Centre s (RC) internal LDAPdirectory and the Portugal Telecom Research Centre s (PT) internal LDAP directory. RC runs the iplanet Directory on Solaris 8 and PT a Microsoft LDAP front-end for Active Directory. 76

90 After setting the machines up and installing the required software, the testing and evaluation could commence. In addition to the author, several users participated in the testing phase of the S/SSO implementation from around Europe, using both file- and smart card based X.509v3 certificates. The author was able to authenticate all of the test users with their certificates into the test realm after some setup related problems were resolved. In addition, single sign-on was successfully tested between the various servers. For comparison and debugging purposes, Basic-authentication was also successfully tested Structure of the sites to be protected The sites protected in this test bed were all stand-alone sites with two categories of pages, protected and public. All protected pages required certificate authentication, and in most cases, the user certificate resided on a smart card. All sites had the SiteMinder agent running in native plug-in, mode and only one agent acted as the cookie provider for the entire authentication realm. This agent resided on netra3 the policy server along with the SSL Credential Collector. All sites belonged to the same authentication and single sign-on realm called Test Realm. The sites permitted access to the public front page shown in Figure 7.5 The public jump page from netra3.rc.elisa.fi, and from here links to the other sites and to the protected content on the server. When a client accessed the site in question he was shown the public front page and prompted for authentication if he placed a request for a protected resource. Once the client had been authenticated on any one of the server hosts, he was able to access the protected items on every host in the Test Realm. It would have been possible to specify multiple levels of authentication but smart card login was deemed secure enough for this test. 77

91 Figure 7.5 The public jump page from netra3.rc.elisa.fi In Figure 7.5 The public jump page from netra3.rc.elisa.fi the front page where the client could select either to access the local protected resource or navigate to one of the affiliate sites in the S/SSO realm. Below in Figure 7.6 SiteMinder administration console front page is the protected resource of netra3.rc.elisa.fi the SiteMinder administrations console front page: 78

92 Figure 7.6 SiteMinder administration console front page From this page the administration console for SiteMinder is loaded as a Java applet applications to any host running a Java compliant run-time environment and having the required three-factor (PIN + certificate and basic authentication on top of that) authentication information The SiteMinder graphical administration user interface Figure 7.7 The SiteMinder administration console The graphical SiteMinder administration console in Figure 7.7 The SiteMinder administration console is very intuitive in design and after one has mastered the 79

93 usage logic, modifying the S/SSO infrastructures configuration becomes very efficient. This is one of the best administrations GUIs seen in this test. Figure 7.8 The agent configuration menu illustrates the agents: Figure 7.8 The agent configuration menu From this menu, the agent parameters can be adjusted, and the administrator can revoke agent access when necessary. Next, the directories are introduced to the S/SSO framework in the following Figure 7.9 The user directories : Figure 7.9 The user directories SiteMinder needs to know certain details about the directory, which are the directory s Internet address, the search base and which field contains the distinguished name attribute in the directory. The details of the directory configuration are shown below in Figure 7.10 Directory configuration : 80

94 Figure 7.10 Directory configuration Of course, the directories themselves are configured by LDIF-files with the appropriate directory schemas for SiteMinder to operate on. Figure 7.11 Realms in the S/SSO policy domain Then the configuration of the realm is all put together in the domain control tab in Figure 7.11 Realms in the S/SSO policy domain above where realms are added to policy domains and rules are added to realms as shown in Figure 7.12 Rules for the ptiaa-realm below. A realm can be thought to consist of a single resource, which an agent protects with different access control rules. There can be multiple realms per agent since there may be different access control needs for different parts of a site. 81

95 Figure 7.12 Rules for the ptiaa-realm In this test setup, each site had only one realm, which was associated with the only protected resource residing in that URL-path. There could be multiple rules in a realm and these rules could point to the same resource, because the rules are bound to users in the policy and different rules can exist for different users or groups to the same resource. Finally, a single test policy is shown below in Figure 7.13 SiteMinder policy setup dialog defines acceptable user directories, associated rules and other constraints. The users who are managed by this policy are selected via LDAP queries and are associated with the relevant rules. Figure 7.13 SiteMinder policy setup dialog 82

96 The critical part of SiteMinders certificate support is the certificate mapping component seen in Figure 7.14 Certificate mapping in SiteMinder below where one can tell which attribute is matched in the given directory. For example, it could be that the user profile in the LDAP directory has a name of Jack Smith with the title field of this record equalling the DN-field of his certificate. If SiteMinder was instructed to match the title-field in LDAP with the extracted DNentry of his certificate and they match, then the rules and other information under his LDAP-entry are related to him. Figure 7.14 Certificate mapping in SiteMinder For this to be secure one has to remember that in the first phase of authentication the X.509 client authentication protocol is used to verify the validity of the presented certificate. Additional requirements include that the certifiers publickey certificate has been introduced to the S/SSO environment beforehand by the administrator for certificate path validation purposes. Therefore, the certificates DN-field can be trusted without further cryptographic processing and just match strings with the LDAP entry. Obviously, the LDAP server holding user- and policy information must be well protected by other means to prevent modification of the policy records by rogue persons Product evaluation to requirement specification In this subchapter, the SiteMinder product is evaluated with the requirements specified by the author previously in chapter 5 and the extent of support for each feature is briefly discussed. 83