Authentication protocol and system
1 / 58

Authentication Protocol and System - PowerPoint PPT Presentation

  • Uploaded on

Authentication Protocol and System. Yuan Xue. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Authentication Protocol and System' - lee-brennan

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Authentication basics
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

Authentication basics1
Authentication Basics

  • Types of Authentication

    • One-way authentication vs. Mutual authentication

    • One-time Authentication vs. combined with key exchange (part of secure communication)



+Key exchange


Secure communication


Authentication approaches
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

Cryptographic authentication
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



Cryptographic authentication1
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


Cryptographic authentication2
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.

Cryptographic authentication3
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)

Authentication using symmetric key distributed one way authentication
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





Authentication using symmetric key distributed one way authentication1
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





Authentication using symmetric key distributed mutual authentication
Authentication using Symmetric-Key(Distributed Mutual Authentication)

  • E(KAB, R)

  • H(KAB||R)

  • Limitation

    • Too many messages

    • Could we reduce them?

I’m Alice




F(KAB, R1)


F(KAB, R2)

Authentication using symmetric key distributed mutual authentication1

I’m Alice, R2

I’m Alice

R1, F(KAB, R2)






F(KAB, R1)

F(KAB, R1)


F(KAB, R2)

Authentication using Symmetric-Key(Distributed Mutual Authentication)


Any Problem?

Reflection attack
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)



F(KAB, R1)

Flawed protocol design

I’m Alice, R2

R1, F(KAB, R2)



I’m Alice, R1



R3, F(KAB, R1)

F(KAB, R1)

This is what’s going to happen

Reflection attack solutions
Reflection Attack -- Solutions


  • 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)



E(KAB, f(R1))

Authentication using symmetric key kdc based authentication
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

Step 1

Both are vulnerable to replay attack

Step 1


E[KB, Ks||IDA]

  • Similar to Secret Key Distribution

  • Important Issue

    • Replay attack

  • Solution

    • Use of nonce

    • Use of timestamp


E[KA, Ks||IDB||N1||ticket]



E[KB, Ks||IDA]



E[KB, Ks||IDA||T2]


E[KA, Ks||IDB||T1||ticket]



E[KB, Ks||IDA ||T2]


Step 2
Step 2


E[KB, Ks||IDA||T2]

  • Combine two one-way distributed authentication procedure


E[KA, Ks||IDB||T1||ticket]

E[KB, Ks||IDA ||T2], E[Ks, N2]



E[Ks, f(N2), N3]

E[Ks, f(N3)]


  • 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)

Authentication vs key distribution
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

Single sign on
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.

Pros and cons of sso
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.

Single sign on design basics
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

Sso security implications
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

Sso mechanisms
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.

Sso dependencies
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

Simple sso operation

Authentication Domain

Secondary domain



1. Access application

2. Refer for authn.

3. Ask for


SSO Application

4. Transfer to application



(Ticket Granting Ticket)

Transfer/Service ticket

Secondary domain

Simple SSO operation

Sso components

HTTP server

SSO Application


Enforcement agent

  • LDAP

  • Kerberos


Authentication server

SSO Components

Sign-on (verification)

App (enforcement)


Products and systems
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

Supported authentication methods


LDAP server (OpenLDAP, Active Directory)

Kerberos (MIT, Active Directory)


Kerberos v5

LDAP server



MIT Kerberos



Supports GSSAPI






Supported Authentication Methods

Central authentication service cas
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.

Cas operation


  • 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.

Webauth operation


  • 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.

Cosign operation


  • 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.

Authentication in a select choose your own method and strength
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

Choosing an sso system
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

Further readings
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

Password basics
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.


Password based authentication
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



Password storage
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.

Password cracking
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

Password cracking cont d
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.

Address based authentication
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

Address based authentication1
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.

Address based authentication2
Address-based Authentication

  • File format

    • hostname [username]

    • + anyhost/user

  • Example hosts.equiv entries ( Local computer A )

    • + + 

      • Allows any user from any host to connect to A

    • B + 

      • Allows any user from the remote hosts B to connect to A.

    • + Alice 

      • Allows the user Alice to connect to A from any remote host.

Address based authentication3
Address-based Authentication

  • Example .rhosts entries

    • In these examples, the .rhosts file is located as the home directory of the user Alice on computer A.

    • + + 

      • Allows any user from any host to connect to this host (A) as the user Alice.

    • B Bob 

      • Allows the user Bob from the remote host B to connect to A as the user Alice.

Address based authentication4
Address-based Authentication

  • How the hosts.equiv and the .rhosts file combine

    • Rule: the most restrictive combination of the entries applies

    • hosts.equiv file with <+ Alice>

    • .rhosts in the home directory of the user Alice with the following entry: B +

    • In this case, these entries combine to mean that only the user Alice from the remote host B can connect to A as Alice.

Issues with address based authentication
Issues With Address-based Authentication

  • Entry <+ +>  severe security hazards

    • It allows any user on any machine to connect to the local host as the same user name.

    • If it is specified in the /etc/hosts.equiv file, it allows any user on any machine to connect to the local host as any user.

  • If A trusts B and B is hacked, then the attacker could gain access to A.

  • Network address impersonation (address spoofing)

Authentication summary
Authentication Summary

  • Types

    • One-way vs. Mutual

    • authentication-only vs. secure data communication

      (any authentication only protocol is vulnerable to man-in-the-middle attack)

  • Secure communication

    • An initial authentication handsake

    • Distribution of session keys

    • Then integrity protection and/or encryption of the data

  • Approaches

    • Symmetric key (KDC, distributed), Asymmetric key

  • Authentication Service

    • Kerberos (composed Needham-Schroeder protocol)

  • Attacks to Authentication

    • Replay Attack (use of Nonce/Timestamp)

    • Reflection Attack

Timestamp vs nonce
Timestamp vs. Nonce

  • Both are used to prevent replay

  • Timestamp

    • needs synchronized system

    • Timestamp itself shows the “freshness” of the message

      • Use fewer messages

    • Has a implicit structure

    • More suitable for connectionless communication

  • Nonce

    • Nonce itself does not show anything about the “freshness”. It has to come in the form of challenge-response pair

      • more messages

    • Structure on Nonce to prevent reflection attack

    • Challenge (N) can be encrypted, response encrypts a function of N (f(N))

      • Encrypted challenge ensures the randomness (unpredictable) of the nounce

      • If N has a structure, encrypted N is a weak way to show one’s ID in the challenge (no timing info, could be a replay)


  • How to retrieve the key

    • Computer: easy

    • Human can not remember the key

      • How to convernt password  key

      • Doing a hash of the password

      • Using the password to encrypt/decrypt a key which is stored in a computer/dir service


  • Required Readings

    • [WS] 15.1-15.4

  • Suggested Reading

    • [KPS] Chapter 11