Outline

• User authentication
– Password authentication, salt
– Challenge-response authentication protocols
– Biometrics
– Token-based authentication
• Authentication in distributed systems (multi
service providers/domains)
– Single sign-on, Microsoft Passport
– Trusted Intermediaries (KPC and CA)
 Objectives
• Understand the four major individual authentication
mechanisms and their comparison
• Understand the basic mechanisms of trusted
intermediaries for distributed authentication using
different crypto methods
– Symmetric key: KDC (the key concept of ticket)
– Asymmetric key: CA
• Know the practical protocols of distributed authentication
– Symmetric key: Kerberos
– Asymmetric key: X.509
 Password authentication
• Basic idea
– User has a secret password
– System checks password to authenticate user
• Issues
– How is password stored?
– How does system check password?
– How easy is it to guess a password?
• Difficult to keep password file secret, so best if it is hard
to guess password even if you have the password file
 Basic password scheme

User Password file

kiwifruit
exrygbzyf
kgnosfix
hash function ggjoklbsz
…
…
 Basic password scheme
• Hash function h : strings  strings
– Given h(password), hard to find password
– No known algorithm better than trial and error
• User password stored as h(password)
• When user enters password
– System computes h(password)
– Compares with entry in password file
• No passwords stored on disk
 Unix password system
• Hash function is 25xDES
– 25 rounds of DES-variant encryptions
• Any user can try “dictionary attack”

R.H. Morris and K. Thompson, Password security: a case

history, Communications of the ACM, November 1979
 UNIX Password System
• Password line
walt:fURfuu4.4hY0U:129:129:Belgers:/home/walt:/bin/csh

Compare
Salt
Input
Constant, Key
Ciphertext
A 64-bit block of 0 25x DES
Plaintext
 Dictionary Attack – some numbers
• Typical password dictionary
– 1,000,000 entries of common passwords
• people's names, common pet names, and ordinary words.

– Suppose you generate and analyze 10 guesses per second

• This may be reasonable for a web site; offline is much faster

– Dictionary attack in at most 100,000 seconds = 28 hours, or 14 hours

on average

• If passwords were random

– Assume six-character password
• Upper- and lowercase letters, digits, 32 punctuation characters

• 689,869,781,056 password combinations.

• Exhaustive search requires 1,093 years on average

 Outline
• User authentication
– Password authentication, salt
– Challenge-response authentication protocols
– Biometrics
– Token-based authentication
• Authentication in distributed systems (multi
service providers/domains)
– Single sign-on, Microsoft Passport
– Trusted Intermediaries
Challenge-response Authentication

Goal: Bob wants Alice to “prove” her identity to

him
Protocol ap1.0: Alice says “I am Alice”

“I am Alice”
Failure scenario??
 Authentication
Goal: Bob wants Alice to “prove” her identity to
him
Protocol ap1.0: Alice says “I am Alice”

in a network,
Bob can not “see”
Alice, so Trudy simply
“I am Alice” declares
herself to be Alice
 Authentication: another try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address

Alice’s
IP address
“I am Alice”

Failure scenario??
 Authentication: another try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address

Trudy can create

a packet
Alice’s
“spoofing”
IP address
“I am Alice” Alice’s address
 Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.

Alice’s Alice’s
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr
 Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.

Alice’s Alice’s
“I’m Alice”
IP addr password
playback attack: Trudy
Alice’s records Alice’s packet
OK
IP addr and later
plays it back to Bob

Alice’s Alice’s
“I’m Alice”
IP addr password
 Authentication: yet another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.

Alice’s encrypted
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr
 Authentication: another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.

Alice’s encryppted
IP addr password
“I’m Alice” record
and
Alice’s
OK playback
IP addr
still works!

Alice’s encrypted
“I’m Alice”
IP addr password
 Authentication: yet another try
Goal: avoid playback attack
Nonce: number (R) used only once –in-a-lifetime
ap4.0: to prove Alice “live”, Bob sends Alice nonce, R.
Alice
must return R, encrypted with shared secret key
“I am Alice”

R
KA-B(R) Alice is live, and
only Alice knows
key to encrypt
nonce, so it must
Failures, drawbacks? be Alice!
 Authentication: ap5.0
ap4.0 doesn’t protect against server database reading
• can we authenticate using public key techniques?
ap5.0: use nonce, public key cryptography
“I am Alice”
Bob computes
R + -
- KA(KA (R)) = R
K A (R) and knows only Alice
could have the private
key, that encrypted R
such that
+ -
K (K (R)) = R
A A
 Outline
• User authentication
– Password authentication, salt
– Challenge-response authentication protocols
– Biometrics
– Token-based authentication
• Authentication in distributed systems (multi
service providers/domains)
– Single sign-on, Microsoft Passport
– Trusted Intermediaries
 Biometrics
• Use a person’s physical characteristics
– fingerprint, voice, face, keyboard timing, …
• Advantages
– Cannot be disclosed, lost, forgotten
• Disadvantages
– Cost, installation, maintenance
– Reliability of comparison algorithms
• False positive: Allow access to unauthorized person
• False negative: Disallow access to authorized person

– Privacy?
– If forged, how do you revoke?
 Biometrics
• Common uses
– Specialized situations, physical security
– Combine
• Multiple biometrics
• Biometric and PIN
• Biometric and token
 Token-based Authentication
Smart Card
• With embedded CPU and memory
– Carries conversation w/ a small card reader
• Various forms
– PIN protected memory card
• Enter PIN to get the password
– PIN and smart phone based token
• Google authentication
– Cryptographic challenge/response cards
• Computer create a random challenge
• Enter PIN to encrypt/decrypt the challenge w/ the card
 Smart Card Example
Initial data (PIN)

Time Challenge Time

function

• Some complications
– Initial data (PIN) shared with server
• Need to set this up securely

• Shared database for many sites

– Clock skew
 Group Quiz
• Suppose Bob is a stateless server which does
not require him to remember the challenge he
sends to Alice. Is the following protocol
secure?

“I am Alice”

R
R, A-B
K (R)
 Outline
• User authentication
– Password authentication, salt
– Challenge-Response
– Biometrics
– Token-based authentication
• Authentication in distributed systems
– Single sign-on, Microsoft Passport
– Trusted Intermediaries
 Single sign-on systems

LAN

Rules Database

user name,
password, Authentication Application
other auth

Server

• Advantages
– User signs on once
– No need for authentication at multiple sites, applications
– Can set central authorization policy for the enterprise
 Microsoft Passport
• Launched 1999
– Claim > 200 million accounts in 2002
– Over 3.5 billion authentications each month
• Log in to many websites using one account
– Used by MS services Hotmail, MSN Messenger or
MSN subscriptions; also Radio Shack, etc.
– Hotmail or MSN users automatically have
Microsoft Passport accounts set up
Passport log-in
 Trusted Intermediaries
Symmetric key problem: Public key problem:
• How do two entities • When Alice obtains
establish shared secret Bob’s public key (from
key over network? web site, e-mail,
diskette), how does she
Solution: know it is Bob’s public
• trusted key distribution key, not Trudy’s?
center (KDC) acting as
Solution:
intermediary between
entities • trusted certification
authority (CA)
 Key Distribution Center (KDC)
• Alice, Bob need shared symmetric key.
• KDC: server shares different secret key with each
registered user (many users)
• Alice, Bob know own symmetric keys, KA-KDC KB-KDC , for
communicating with KDC.
KDC

KA-KDC KP-KDC
KX-KDC
KP-KDC KB-KDC
KY-KDC

KZ-KDC
KA-KDC KB-KDC
 Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared
symmetric secret key to communicate with each other?

Alice and Bob communicate: using R1 as

session key for shared symmetric encryption
 Ticket and Standard Using KDC
• Ticket
– In KA-KDC(R1, KB-KDC(A,R1) ), the KB-KDC(A,R1) is also
known as a ticket
– Comes with expiration time
• KDC used in Kerberos: standard for shared key
based authentication
– Users register passwords
– Shared key derived from the password
 Kerberos
• Trusted key server system from MIT
– one of the best known and most widely implemented
trusted third party key distribution systems.
• Provides centralised private-key third-party
authentication in a distributed network
– allows users access to services distributed through
network
– without needing to trust all workstations
– rather all trust a central authentication server
• Two versions in use: 4 & 5
• Widely used
– Red Hat 7.2 and Windows Server 2003 or higher
 Two-Step Authentication

 Prove identity once to obtain special TGS ticket

 Use TGS to get tickets for any network service

USER=Joe; service=TGS
Joe the User
Encrypted TGS ticket
Key distribution
center (KDC)
TGS ticket
Ticket granting
Encrypted service (TGS)
service ticket

Encrypted File server, printer,

service ticket other network services
slide 35
 Still Not Good Enough
• Ticket hijacking
– Malicious user may steal the service ticket of another
user on the same workstation and use it
• IP address verification does not help

– Servers must verify that the user who is presenting the

ticket is the same user to whom the ticket was issued

slide 36
 Symmetric Keys in Kerberos
• Kc is long-term key of client C
– Derived from user’s password
– Known to client and key distribution center (KDC)

• KTGS is long-term key of TGS

– Known to KDC and ticket granting service (TGS)

• Kv is long-term key of network service V

– Known to V and TGS; separate key for each service

• Kc,TGS is short-term key between C and TGS

– Created by KDC, known to C and TGS

• Kc,v is short-term key betwen C and V

– Created by TGS, known to C and V
slide 37
 “Single Logon” Authentication
kinit program (client)
Key Distribution
Center (KDC)
password IDc , IDTGS , timec
Convert into
client master key

User Kc EncryptKc(Kc,TGS , IDTGS , timeKDC ,

lifetime , ticketTGS)
Decrypts with
Kc and obtains Fresh key to be used
between client and TGS
Kc,TGS and TGS Key = KTGS
ticketTGS EncryptKTGS(Kc,TGS , IDc , Addrc , Key = Kc
IDTGS , timeKDC , lifetime) …
Client will use this unforgeable ticket to
get other tickets without re-authenticating All users must
pre-register their
passwords with KDC

• Client only needs to obtain TGS ticket once (say, every morning)
– Ticket is encrypted; client cannot forge it or tamper with it slide 38
 Obtaining a Service Ticket
Client EncryptKc,TGS(IDc , Addrc , timec) Ticket Granting
Proves that client knows key K c,TGS Service (TGS)
Knows Kc,TGS contained in encrypted TGS ticket usually lives inside KDC
and ticketTGS

System command, IDv , ticketTGS , authC

e.g. “lpr –Pprint”

User EncryptKc,TGS(Kc,v , IDv , timeTGS ,

ticketv)
Fresh key to be used
between client and service Knows key Kv for
each service

EncryptKv(Kc,v , IDc , Addrc , IDv ,

timeTGS , lifetime)
Client will use this unforgeable
ticket to get access to service V

• Client uses TGS ticket to obtain a service ticket and a short-term

key for each network service
slide 39
– One encrypted, unforgeable ticket per service (printer, email, etc.)
 Obtaining Service
Client EncryptKc,v(IDc , Addrc , timec)
Proves that client knows key K c,v
Knows Kc,v
and ticketv
contained in encrypted ticket
Server V
System command, ticketv , authC
e.g. “lpr –Pprint”

User EncryptKc,v(timec+1)

Authenticates server to client

Reasoning:
Server can produce this message only if he knows key Kc,v.
Server can learn key K c,v only if he can decrypt service ticket.
Server can decrypt service ticket only if he knows correct key K v.
If server knows correct key Kv, then he is the right server.

• For each service request, client uses the short-term key for that
service and the ticket he received from TGS slide 40
Kerberos 4 Overview
 Important Ideas in Kerberos
• Short-term session keys
– Long-term secrets used only to derive short-term keys
– Separate session key for each user-server pair
• … but multiple user-server sessions re-use the same key

• Proofs of identity are based on authenticators

– Client encrypts his identity, address and current time using a
short-term session key
• Also prevents replays (if clocks are globally synchronized)

– Server learns this key separately (via encrypted ticket that client
can’t decrypt) and verifies user’s identity
• Symmetric cryptography only
slide 42
 Practical Uses of Kerberos
• Email, FTP, network file systems and many
other applications have been kerberized
– Use of Kerberos is transparent for the end user
– Transparency is important for usability!
• Local authentication
– login and su in OpenBSD
• Authentication for network protocols
– rlogin, rsh, telnet
 Trusted Intermediaries
Symmetric key problem: Public key problem:
• How do two entities • When Alice obtains
establish shared secret Bob’s public key (from
key over network? web site, e-mail,
diskette), how does she
Solution: know it is Bob’s public
• trusted key distribution key, not Trudy’s?
center (KDC) acting as
Solution:
intermediary between
entities • trusted certification
authority (CA)
 Certification Authorities
• Certification authority (CA): binds public key to
particular entity, E.
• E (person, router) registers its public key with CA.
– E provides “proof of identity” to CA.
– CA creates certificate binding E to its public key.
– Certificate containing E’s public key digitally signed by CA
– CA says “this is E’s public key”

Bob’s digital
+
public +
signature KB
key KB (encrypt)
CA
certificate for
K-
Bob’s private
identifying key CA Bob’s public key,
information signed by CA
 Certification Authorities
• When Alice wants Bob’s public key:
– gets Bob’s certificate (Bob or elsewhere).
– apply CA’s public key to Bob’s certificate, get Bob’s
public key
• CA is heart of the X.509 standard used extensively in
– SSL (Secure Socket Layer)/TLS: deployed in every Web browser
– S/MIME (Secure/Multiple Purpose Internet Mail Extension), and
IP Sec, etc.
+ digital Bob’s
KB signature public
+
(decrypt) K B key

CA
public +
K CA
key
 General Process of SSL
Version, Crypto choice, nonce

Version, Choice, nonce,

signed certificate
containing server’s
public key Ks

C Secret key K
encrypted with S
server’s key Ks

switch to negotiated cipher

hash of sequence of messages

hash of sequence of messages
 Authentication in SSL/HTTPS
• Company asks CA (e.g., Verisign) for a certificate
• CA creates certificates and signs it
• Certificate installed in server (e.g., web server)
• Browser issued with root certificates
– Windows Root Certificates List
• http://social.technet.microsoft.com/wiki/contents/articles/25
92.aspx

• Browser verify certificates and trust correctly

signed ones
 Single KDC/CA
• Problems
– Single administration trusted by all principals
– Single point of failure
– Scalability
• Solutions: break into multiple domains
– Each domain has a trusted administration
 Multiple KDC/CA Domains
Secret keys:
• KDCs share pairwise key
• topology of KDC: tree with shortcuts
Public keys:
• cross-certification of CAs
• example: Alice with CAA, Boris with CAB
– Alice gets CAB’s certificate (public key p1), signed by CAA
– Alice gets Boris’ certificate (its public key p2), signed by
CAB (p1)
 Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared
symmetric secret key to communicate with each other?

KDC
generates
KA-KDC(A,B)
R1

Alice KA-KDC(R1, KB-KDC(A,R1) )

Bob knows to
knows use R1 to
R1 KB-KDC(A,R1) communicate
with Alice

Alice and Bob communicate: using R1 as

session key for shared symmetric encryption
 Group Quiz

Consider the KDC and CA servers.

Suppose a KDC goes down. What is
the impact on the ability of parties
to communicate securely; that is,
who can and cannot communicate?
Justify your answer. Suppose now
a CA goes down. What is the impact
of this failure? 
Backup Slides
 Advantages of salt
• Without salt
– Same hash functions on all machines
• Compute hash of all common strings once
• Compare hash file with all known password files

• With salt
– One password hashed 212 different ways
• Precompute hash file?
– Need much larger file to cover all common strings

• Dictionary attack on known password file

– For each salt found in file, try all common strings
 Four parts of Passport account
• Passport Unique Identifier (PUID)
– Assigned to the user when he or she sets up the account
• User profile, required to set up account
– Phone number or Hotmail or MSN.com e-mail address
– Also name, ZIP code, state, or country, …
• Credential information
– Minimum six-character password or PIN
– Four-digit security key, used for a second level of
authentication on sites requiring stronger sign-in credentials
• Wallet
– Passport-based application at passport.com domain
– E-commerce sites with Express Purchase function use wallet
information rather than prompt the user to type in data
 Kerberos in Large Networks
• One KDC isn’t enough for large networks (why?)
• Network is divided into realms
– KDCs in different realms have different key databases
• To access a service in another realm, users must…
– Get ticket for home-realm TGS from home-realm KDC
– Get ticket for remote-realm TGS from home-realm TGS
• As if remote-realm TGS were just another network service

– Get ticket for remote service from that realm’s TGS

– Use remote-realm ticket to access service
– N(N-1)/2 key exchanges for full N-realm interoperation
slide 56
 When NOT Use Kerberos
• No quick solution exists for migrating user
passwords from a standard UNIX password
database to a Kerberos password database
– such as /etc/passwd or /etc/shadow
• For an application to use Kerberos, its source must
be modified to make the appropriate calls into the
Kerberos libraries
• All-or-nothing proposition
– If any services that transmit plaintext passwords remain
in use, passwords can still be compromised