authentication protocol and system

@Yuan Xue ([email protected])

Authentication Protocol and System

Yuan Xue


Authentication BasicsUser 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 userData 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 Basics

Types of Authentication One-way authentication vs. Mutual authentication One-time Authentication vs. combined with key

exchange (part of secure communication)

AuthenticationAuthentication+Key exchange

Key

Secure communication(encryption+MAC)


Authentication Approaches

Cryptographic (Focus)

Password-based

Address-based

Other approaches Bio-metrics

• What you know

• What you have

• Who you are

• Where you are

Basic Guideline


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

authentication

What you Know/have


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

Priori: Alice and Bob share a master keyResult: Alice proves her identity to Bob

Alice Bob

I’m Alice

R

F(KAB, R)

• E(KAB, R)• H(KAB||R)


Authentication using Symmetric-Key(Distributed One-Way Authentication)

Priori: Alice and Bob share a master keyResult:

Alice proves her identity to Bob; If R is a timestamp, Bob can also prove his identity (mutual authentication)

Requires reversible cryptography

Alice Bob

I’m Alice

R

E(KAB, R)


Authentication using Symmetric-Key(Distributed Mutual Authentication)

Limitation Too many messages Could we reduce them?

Alice Bob

I’m Alice

R1

F(KAB, R1)

• E(KAB, R)• H(KAB||R)

R2

F(KAB, R2)


Authentication using Symmetric-Key(Distributed Mutual Authentication)

Alice Bob

I’m Alice, R2

R1, F(KAB, R2)

F(KAB, R1)Simplify

Alice Bob

I’m Alice

R1

F(KAB, R1)

R2

F(KAB, R2)

Any Problem?


Reflection Attack

Alice Bob

I’m Alice, R2

R1, F(KAB, R2)

F(KAB, R1)

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.

Bob

I’m Alice, R1

R3, F(KAB, R1)Cathy

Bob

I’m Alice, R2

R1, F(KAB, R2)Cathy

F(KAB, R1)

Flawed protocol design

This is what’s going to happen


Reflection Attack -- SolutionsPrinciple:

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.

Alice Bob

I’m Alice, E(KAB, R2)

E(KAB, f(R2)||R1)

E(KAB, f(R1))


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

Similar to Secret Key DistributionImportant Issue

Replay attack

Solution Use of nonce Use of

timestamp

IDA||IDB||N1E[KA, Ks||IDB||N1||ticket]

E[KB, Ks||IDA]

Needham-Schroeder

Both are vulnerable to replay attack

A BE[KB, Ks||IDA]

KDC

IDA||IDB||T1E[KA, Ks||IDB||T1||ticket]

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

A BE[KB, Ks||IDA ||T2]

KDC

Kerberos


Step 2

Combine two one-way distributed authentication procedure

IDA||IDB||T1E[KA, Ks||IDB||T1||ticket]

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

A B

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

KDC

E[Ks, f(N2), N3]

E[Ks, f(N3)]


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 DistributionCryptographic 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 OnBackground 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 SSOPros

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

Credentials never leave the authentication domainSecondary (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 MechanismsIn 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 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

Application/resource

SSO Application

Application/resource

1. Access application

2. Refer for authn.3. Ask for

credentials 4. Transfer to application

Authentication Domain Secondary domain

Secondary domain

SSOSession(Ticket

Granting Ticket)

Transfer/Service ticket


SSO Components

Authentication server

SSO Application

HTTP server

• LDAP

• Kerberos

• RDBMS

• …

Application

Enforcement agent

Sign-on (verification) App (enforcement)

Authorisation


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


Let’s look at some example SSO systems


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.


CASOperation


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


WebAuthOperation


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


CoSignOperation


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


overview


Authentication in A-Selectchoose your own method (and strength)

IP addressUsername / password

LDAP / Active Directory

RADIUS SQL

PassfacesPKI certificateOTP through SMSOTP through internet bankingTokens (SecurID, Vasco, …)Biometrics


Choosing an SSO systemNeed 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

Evaluation of Web Single Sign-On TechnologiesWebSSO Implementation ComparisonWeb Single Sign On Evaluation Whitepaper Understanding Single Sign-on Build and implement a single sign-on solution


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

Authentication based on password (what you know)

Pro Easy to use

Con Insecure: Eavesdropping Solution combine with cryptography-based

approaches

Alice BobI’m Alice, my passwd is 123456


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

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



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



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.



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

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 SummaryTypes

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


MiscHow 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

Required Readings [WS] 15.1-15.4

Suggested Reading [KPS] Chapter 11

authentication protocol and system

Documents