authentication protocol and system
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
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?
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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))
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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)]
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
@Yuan Xue ([email protected])
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
SSO Components
Authentication server
SSO Application
HTTP server
• LDAP
• Kerberos
• RDBMS
• …
Application
Enforcement agent
Sign-on (verification) App (enforcement)
Authorisation
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
Let’s look at some example SSO systems
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
CASOperation
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
WebAuthOperation
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
CoSignOperation
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
overview
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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.
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
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)
@Yuan Xue ([email protected])
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
@Yuan Xue ([email protected])
Readings
Required Readings [WS] 15.1-15.4
Suggested Reading [KPS] Chapter 11