Authentication protocol and system
This presentation is the property of its rightful owner.
Sponsored Links
1 / 58

Authentication Protocol and System PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Authentication Protocol and System

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 protocol and system

Authentication Protocol and System

Yuan Xue


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)

Authentication

Authentication

+Key exchange

Key

Secure communication

(encryption+MAC)


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

Know/have

authentication


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

Know/have


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

R

Alice

Bob

F(KAB, R)


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

E(KAB, R)

Alice

Bob

R


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

R1

Alice

Bob

F(KAB, R1)

R2

F(KAB, R2)


Authentication using symmetric key distributed mutual authentication1

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?


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)

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


Reflection attack solutions

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


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

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


Step 2

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


Kerberos

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)


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

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


Sso components

HTTP server

SSO Application

Application

Enforcement agent

  • LDAP

  • Kerberos

  • RDBMS

Authentication server

SSO Components

Sign-on (verification)

App (enforcement)

Authorisation


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

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


Let s look at some example sso systems

Let’s look at some example SSO systems


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

CASOperation


Webauth

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.


Webauth operation

WebAuthOperation


Cosign

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.


Cosign operation

CoSignOperation


Pubcookie

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.


Authentication protocol and system

overview


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.

Reference: http://en.wikipedia.org/wiki/Password

http://en.wikipedia.org/wiki/Password_cracking


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

Bob

Alice


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)


Authentication protocol and system

Misc

  • 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


Readings

Readings

  • Required Readings

    • [WS] 15.1-15.4

  • Suggested Reading

    • [KPS] Chapter 11


  • Login