Authentication Protocol and System

1. Authentication Protocol and System Yuan Xue

2. Authentication Basics • User Authentication is the process of reliably verifying the identity of someone (or something) • A computer/application/system authenticates another computer • A computer authenticates a person • User’s secret must be remembered by the user • Data Authentication(Integrity) • Integrity = data integrity + source authentication + non-repudiation • Source authentication vs. non-repudiation • Source authentication protects communication parties from the third party • Non-repudiation protects the communication parties from each other • MAC  data integrity + data source authentication • Digital Signature  data integrity + data source authentication + non-repudiation

3. Authentication Basics • Types of Authentication • One-way authentication vs. Mutual authentication • One-time Authentication vs. combined with key exchange (part of secure communication) Authentication Authentication +Key exchange Key Secure communication (encryption+MAC)

4. Authentication Approaches • Cryptographic (Focus) • Password-based • Address-based • Other approaches • Bio-metrics Basic Guideline • What you know • What you have • Who you are • Where you are

5. Cryptographic Authentication • For connection-oriented communication, overall process involves authentication + secure communication (connection) • Based on prior knowledge/ownership of master key • Dependably verify the knowledge/ownership of key • Distribution of session keys • integrity protection and/or encryption of the data using session keys What you Know/have authentication

6. Cryptographic Authentication • For connection-less communication, overall process involves authentication + data transmission • Based on prior knowledge/ownership of key • Generation of data encryption/MAC generation keys • integrity protection and/or encryption of the data using data encryption/MAC generation keys • One time authentication • prove driver’s identify to a secured gate. • Login to a computer system locally What you Know/have

7. Cryptographic Authentication • Basic idea • Alice proves her identity to Bob by performing a cryptographic operation on a quantity (challenge) Bob supplies. • The cryptographic operation performed by Alice is based on Alice’s key. • Cryptographic operations include • Symmetric key encryption, asymmetric key encryption, hash operations.

8. Cryptographic Authentication • Approaches • Symmetric-key based • Distributed (communication peers share a master key) • KDC-based (communication peers share master keys with KDC) • Asymmetric-key based • Two types of authentication • One-way authentication (login only) • Mutual authentication • Other issues • How to retrieve the key (human being can not remember it)

9. Authentication using Symmetric-Key(Distributed One-Way Authentication) • Priori: Alice and Bob share a master key • Result: Alice proves her identity to Bob • E(KAB, R) • H(KAB||R) I’m Alice R Alice Bob F(KAB, R)

10. Authentication using Symmetric-Key(Distributed One-Way Authentication) • Priori: Alice and Bob share a master key • Result: • Alice proves her identity to Bob; • If R is a timestamp, Bob can also prove his identity (mutual authentication) • Requires reversible cryptography I’m Alice E(KAB, R) Alice Bob R

11. Authentication using Symmetric-Key(Distributed Mutual Authentication) • E(KAB, R) • H(KAB||R) • Limitation • Too many messages • Could we reduce them? I’m Alice R1 Alice Bob F(KAB, R1) R2 F(KAB, R2)

12. I’m Alice, R2 I’m Alice R1, F(KAB, R2) Alice Bob R1 Alice Bob F(KAB, R1) F(KAB, R1) R2 F(KAB, R2) Authentication using Symmetric-Key(Distributed Mutual Authentication) Simplify Any Problem?

13. Reflection Attack I’m Alice, R2 Reflection attack • A way of attacking a challenge-response authentication system which uses the same protocol in both directions. • The basic idea is to trick the target into providing the answer to its own challenge. R1, F(KAB, R2) Alice Bob F(KAB, R1) Flawed protocol design I’m Alice, R2 R1, F(KAB, R2) Cathy Bob I’m Alice, R1 Cathy Bob R3, F(KAB, R1) F(KAB, R1) This is what’s going to happen

14. Reflection Attack -- Solutions Principle: • Don’t have Alice and Bob do exactly the same thing • Different protocol along the two directions • The responder sends its identifier within the response, so if it receives a response that has its identifier in it, it can reject it. • Have the initiator prove its identity first • Initiating party to first respond to challenges before the target party responds to its challenges. I’m Alice, E(KAB, R2) E(KAB, f(R2)||R1) Alice Bob E(KAB, f(R1))

15. Authentication using Symmetric-Key(KDC-based Authentication) • Basic idea • KDC and A can establish a trust relationship using KA • KDC and B can establish a trust relationship using KB • KDC needs to provide A and B a shared secret based on their master keys so that they could use to authenticate each other • Once A and B has a a shared secret (KS), the procedure used in distributed symmetric-key-based authentication can be used to perform mutual authentication. • Step 1 • KDC provides A and B a shared secret KS • Step 2 • A and B perform mutual authentication using KS

16. Both are vulnerable to replay attack Step 1 KDC E[KB, Ks||IDA] • Similar to Secret Key Distribution • Important Issue • Replay attack • Solution • Use of nonce • Use of timestamp IDA||IDB||N1 E[KA, Ks||IDB||N1||ticket] B A E[KB, Ks||IDA] Needham-Schroeder KDC E[KB, Ks||IDA||T2] IDA||IDB||T1 E[KA, Ks||IDB||T1||ticket] B A E[KB, Ks||IDA ||T2] Kerberos

17. Step 2 KDC E[KB, Ks||IDA||T2] • Combine two one-way distributed authentication procedure IDA||IDB||T1 E[KA, Ks||IDB||T1||ticket] E[KB, Ks||IDA ||T2], E[Ks, N2] A B E[Ks, f(N2), N3] E[Ks, f(N3)]

18. Kerberos • An Authentication Service • Based on client-server model (user and server provider) • Mutual authentication support: between user and server • Key assumption • The server can not rely on the client host to authenticate user • Basics • KDC-based authentication using symmetric key • Based on Needham-Schroeder protocol • Use “ticket” to distribute the key • Use “authenticator" to prove the identity of a user • Main entities • Authentication Server (AS) • Ticket Granting Server (TGS)

21. Authentication vs. Key Distribution • Cryptographic Authentication • Based on prior knowledge/ownership of key • Dependably verify the knowledge of key • Distribution of session keys (for connection-oriented communication) • Key Distribution • Prior knowledge/ownership of master keys • Distribution of session keys after verification of master keys • Symmetric key • A, B share a master key with KDC • A and B share a master key • Asymmetric key • A and B both have a pair of public and private keys • The public keys of A and B are reliably distributed to each other

22. Single Sign On • Background and Motivation • Web Portals are becoming more and more sophisticated. • Portals need to integrate with back-end resources, each with its own authentication needs and user repositories. • Portals need to authenticate users to back-end data sources and applications, yet these applications may each have different underlying security infrastructures. • Single sign-on Authentication (SSO) is the ideal and most efficient authentication solution • What is Single Sign On? • User only has to log in once and is authenticated to access all of the network resources/applications. • SSO provides a unified mechanism to manage the authentication of users and implement business rules determining user access to applications and data.

23. Pros and Cons of SSO • Pros • Improved user productivity: Users are no longer bogged down by multiple logins and they are not required to remember multiple IDs and passwords. Also, support personnel answer fewer requests to reset forgotten passwords. • Improved developer productivity: SSO provides developers with a common authentication framework. The developer can assume that once a request for an application is accompanied by a username, then authentication has already taken place. • Simplified administration: When applications participate in a single sign-on protocol, the administration burden of managing user accounts is simplified. • Cons • Difficult to retrofit. An SSO solution can be difficult, time-consuming, and expensive to retrofit to existing applications. • Security risks. For example, a malicious user could gain access to a user's all authorized resources once his password is compromised. • Single point of attack. With single sign-on, a single, central authentication service is used by all applications. This is an attractive target for hackers who may decide to carry out a denial of service attack.

24. Single Sign-On Design Basics • There are two main types of SSO architecture types • Web-based  our focus • Non-Web-based.  legacy applications • Two design aspects • SSO needs centralized authentication servers that all other applications and systems utilize for authentication purposes. • SSO has to internally translate to and store different credentials compared to what is used for initial authentication, as different applications and resources support different authentication mechanisms. • SSO usually uses a Kerberos-model

25. SSO Security Implications • Credentials never leave the authentication domain • Secondary (affiliated) domains have to trust the authentication domain • Credentials must be asserted correctly • Protect from unauthorised use • Authentication transfer has to be protected • Replay prevention • Interception/masquerade attacks

26. SSO Mechanisms • In order to relay the authentication credentials, two mechanisms are seen in web-based SSO • Cookies • X.509 certificate • Use of cookies (more details of cookies will be discussed shortly) • When a user is authenticated by the single sign-on system, the authenticating agent plants a cookie, which is essentially a small file of information, into the user’s browser. When the user attempts to access a resource, the end system can request the cookie • Example system: CAS • Use of X.509 • X.509 certificate authenticates the user in SSL • E.g. KX509. User uses their Kerberos Ticket (TGT) to acquire a one-day X.509 certificate. It generates an RSA key-pair and connects to the organization-wide KCA (Kerberised Certificate Authority). It then authenticates as the user to the KCA using standard K4/K5 libraries. Once authenticated, it requests an X.509 certificate for the user with the transmitted public key and gathers information for the X.509 certificate from institutional resources (user's Full Name in particular). The KCA uses this information plus the received public key to generate an X.509 (v3) certificate signed by its CA private key with a validity lifetime of one day.

27. SSO dependencies • SSO system relies on other infrastructure • Authentication system • Requires interface with web server • Identity management/registration • Need to provide for authorisation • Applications often need more than just authentication information • Attribute information • Shibboleth or other architectures

28. Authentication Domain Secondary domain Application/resource Application/resource 1. Access application 2. Refer for authn. 3. Ask for credentials SSO Application 4. Transfer to application SSO Session (Ticket Granting Ticket) Transfer/Service ticket Secondary domain Simple SSO operation

29. HTTP server SSO Application Application Enforcement agent • LDAP • Kerberos • RDBMS • … Authentication server SSO Components Sign-on (verification) App (enforcement) Authorisation

30. Products and Systems • Web Single Sign-on products • GetAccess by Entrust • PortalXpert by Evidian • SiteMinder by Netegrity • ClearTrust by RSA Security • OpenSSO by Sun Java • SSO systems • Central Authentication Service by Yale University. • Pubcookie by the University of Washington • WebAuth by Stanford University (Duke also has a similar system with the same name) • Michigan Cosign and X.509 certificates via Kerberos by University of Michigan • A-Select by Surfnet (Netherlands) • SSO By Google • Legacy Single Sign-on products • ETrust Single Sign-on by Computer Associates • Access Master by Envidian • Tivoli Global Sign-on by IBM • Secure Login by Novell

31. CAS LDAP server (OpenLDAP, Active Directory) Kerberos (MIT, Active Directory) Pubcookie Kerberos v5 LDAP server /etc/shadow WebAuth MIT Kerberos OpenLDAP CoSign Supports GSSAPI A-Select Banking SMS ‘SURFkey’ LDAP Radius Supported Authentication Methods

32. Let’s look at some example SSO systems

33. Central Authentication Service (CAS) • CAS is based on the Kerberos model. • CAS uses an opaque session ID cookie (which is the Ticket Granting Ticket; TGT) that is only ever returned back to the CAS server. This cookie allows the CAS server to validate the user without challenging them to enter their credentials again. • A Web application only ever sees its own Service Ticket (ST), which is associated (on the CAS server) to the TGT for the user. • The ST is a one-time-use-only opaque value that is invalidated when the web application verifies it for the first time.

34. CASOperation

35. WebAuth • WebAuth central authentication services (the WebKDC) share symmetric keys with each WebAuth-Enabled Application Server (WAS) to encrypt or decrypt the tokens sent. Kerberos 5 and SSL are used to bootstrap and get session keys from the WebKDC. • WebAuth uses the cookie to store information about the authenticated user for consumption by Web applications (for example user id, creation and exppiry times etc). • WebAuth uses ID and proxy tokens, which are consumed by the WAS and the main token is only consumed by the WebKDC. All of the tokens are encrypted with the appropriate shared key so only the recipient can read the contents. Since all of the data required is on the cookies, the WAS doesn’t need to communicate with the WebKDC to validate the cookie and then get any user credentials. • All state data for both the WebKDC and the WAS are kept on the user’s browser in the form of cookies. This makes the WebKDC and WAS stateless with respect to the WebAuth application.

36. WebAuthOperation

37. CoSign • Unlike other cookie-based Web authentication solutions, cosign does not use a domain or otherwise public cookie to allow cross-server authentication. • The cosign server has its own cookie and departmental Web servers have their own cookies. • The Cosign cookie is available only to the Cosign server; the departmental service cookies are available only to the departmental servers. • The alternative solution, using a domain cookie, would allow any Web server on campus (including Web servers in student dorms) to compromise the authentication cookie. • Cosign leverages its central state database to allow simple, effective user-initiated log out at the end of a session • The Cosign server configuration includes the option to forward Kerberos tickets to approved target sites. The passing of Kerberos tickets is limited to direct SSL connections between the authentication server and the Web server on the internal network, and is never passed to the browser or anywhere else outside the local network.

38. CoSignOperation

39. Pubcookie • Pubcookie is an open source WebISO solution that was originally developed at the University of Washington in 1998. • In 2001, it was bundled and made available to others in conjunction with efforts at Internet2 to better define web-based initial sign-on (WebISO) systems like Pubcookie itself. • Later that same year, developers at Carnegie Mellon, Wisconsin, and elsewhere joined the effort to make Pubcookie more generally useful and this activity moved the project into the realm of the open-source project where it lives today. The Pubcookie login server has two primary functions: to authenticate users and to issue authentication tokens (granting cookies) consumed by Pubcookie-enabled target application servers. Authentication occurs either by verifying user-provided credentials via a backend authentication service (Kerberos, LDAP, etc.) or by checking a token that was created on a previous visit to the login server. The Pubcookie solution does not forward the Kerberos credentials.

40. overview

41. Authentication in A-Selectchoose your own method (and strength) • IP address • Username / password • LDAP / Active Directory • RADIUS • SQL • Passfaces • PKI certificate • OTP through SMS • OTP through internet banking • Tokens (SecurID, Vasco, …) • Biometrics

42. Choosing an SSO system • Need to evaluate systems appropriate to your environment • Apache/IIS/J2EE • OS/platform support • Will the SSO product integrate with my • authentication system • applications (agent/webserver integration, legacy applications) • authorisation system (Shibboleth support?) • Need to provide resilient system • Single point of failure • Performance/throughput

43. Further Readings • Evaluation of Web Single Sign-On Technologies • WebSSO Implementation Comparison • Web Single Sign On Evaluation WhitepaperUnderstanding Single Sign-on • Build and implement a single sign-on solution

44. Password Basics • A password is a secret word or string of characters that is used for authentication, to prove identity or gain access to a resource. • Criteria to pick a password -- easy to remember, hard to guess. • The passwords must be kept secret. They are usually stored in a file or a database so that the system can perform password verification when a user attempts to log in or access a restricted resource. Reference: http://en.wikipedia.org/wiki/Password http://en.wikipedia.org/wiki/Password_cracking

45. Password-Based Authentication • Authentication based on password (what you know) • Pro • Easy to use • Con • Insecure: Eavesdropping • Solution combine with cryptography-based approaches I’m Alice, my passwd is 123456 Bob Alice

46. Password Storage • To preserve confidentiality of passwords, they are typically not stored in cleartext form. Password storage formats include: • Hash function: a one-way hash function is applied to the password, possibly in combination with other data (e.g., salt), and the resulting value is stored. • When a user later attempts to authenticate by entering the password, the same function is applied to the entered value and the result is compared with the stored value. If they match, there is an extremely high probability that the entered password was correct.

47. Password cracking • Password cracking is the process of recovering passwords from data that has been stored in a computer system or transmitted in the network. • Offline password guessing • Online password guessing • Offline password guessing • The attacker possesses the hashed password can either try to reverse the hash function or test guesses for the password by applying the one-way function to each guess. • Online password guessing • Without the hashed version of a password, the attacker can still attempt access to the computer system in question with guessed passwords. • Solution-- existing systems typically limit the number of failed access attempts

48. Password Cracking (Cont’d) • Password Cracking Methods • Exploit weaknesses of poorly designed password hashing scheme • E.g., LM (LanManager) used in Microsoft Windows XP. • Brute-force and precomputation attacks -- hash a large number of words or random permutations and comparing the result of each guess to stored hashed password. • Solution: Salting • Other ways to obtain passwords • social engineering, keystroke logging, login spoofing, dumpster diving, phishing, shoulder surfing, timing attack, acoustic cryptanalysis, using a Trojan Horse or virus, identity management system attacks (such as abuse of Self-service password reset) and compromising host security.

49. Address-based Authentication • Authentication based on where you are • Infer the identity of the source based on the network address • Example • IEEE Xexplore/ACM DL • Unix rtools • Pro • Easy to use • Transparent to end user

50. Address-based Authentication • In UNIX, hosts.equiv and .rhosts files list hosts and users that are trusted by the local host when a connection is made using the rshd service • A global file /etc/hosts.equiv contains trusted remote hosts. • In each user’s home directory, a per-user .rhosts file contains host-user pairs.