CMSC 414
Computer and Network Security
Lecture 17
Jonathan Katz
Authentication with password +
public key
 Say that only the server has a known public key
(e.g., SSL)
– Server sends R
– Client sends Epk(R, password, session-key)
 Insecure in general!!!
– But secure if encryption scheme is chosen appropriately
 Can be extended to give mutual authentication
Using session keys
 Generally, want to provide both secrecy and
integrity for subsequent conversation
–
–
–
–
Use authenticated encryption (e.g., encrypt-then-MAC)
Use sequence numbers to prevent replay attacks
Use a directionality bit
Periodically refresh the session key
Mediated authentication
(using a KDC)
Mediated authentication
 Simple protocol:
– Alice requests to talk to Bob
– KDC generates KAB and sends it to Alice and Bob,
encrypted with their respective keys
 No authentication here, but impostor can’t
determine KAB
 Other drawbacks:
– KDC has to initiate session with Bob
– Alice’s message to Bob may arrive before KDC’s
message to Bob
Improvement…
 Have KDC send to Alice the encryption of KAB
under Bob’s key
– Reduces communication load on KDC
– Resilient to message delays in network
 Bob and Alice follow with mutual authentication
and key exchange
Needham-Schroeder
 AKDC: N1, Alice, Bob
 KDCA: KA{N1, “Bob”, KAB, ticket}, where
ticket = KB{KAB, “Alice”}
 AB: ticket, KAB{N2}
 BA: KAB{N2-1, N3}
 AB: KAB{N3-1}
Analysis?
 N1 assures Alice that she is talking to KDC
– Prevents key-replay; helps prevent attack when Bob’s
key is compromised and then changed
 “Bob” authenticated in message 2, and “Alice” in ticket
 Uses encryption to authenticate… 
– Leads to flaw if, e.g., ECB mode is used in round 4
 Vulnerable if Alice’s key (even an old one) compromised
– A ticket is eternally valid
– Fix using timestamps, or by requesting an (encrypted)
nonce from Bob at the very beginning of the protocol
Otway-Rees
 AB: N, “Alice”, KA{NA, N, “Alice”, “Bob”}
 BKDC: KA{NA, N, “Alice”, “Bob”},
KB{NB, N, “Alice”, “Bob”}
 KDCB: N, KA{NA, KAB}, KB{NB, KAB}
 BA: KA{NA, KAB}
 AB: KAB(timestamp)
Analysis?
 Why does Alice believe she is talking to Bob?
 Why does Bob believe he is talking to Alice?
 Note: N should be unpredictable, not just a nonce
– Otherwise, can falsely authenticate Bob to Alice
Desiderata and summary
 This is not an exhaustive list!
 These are concerns to be aware of; in some cases
you may decide that certain threats are acceptable
 Better to formally define a security model and
prove security (but here we will be informal)
Desiderata and summary
 Adversary initiating session as client
– (Easiest attack to carry out)
– No impersonation (obviously!)
– No off-line password guessing
– Should not learn information that will subsequently
allow impersonation of server to client
– Be aware of server decrypting/signing unauthenticated
challenges
– Splicing messages into the session
 Similar for adversary accepting connections from
client (though this is a harder attack)
Desiderata and summary
 Eavesdropping
– Should not learn information that would allow for later
impersonation (possibly to another replica of Bob)
– Messages should be encrypted
– No off-line dictionary attacks
 Server compromise
– Should not learn client’s password
– Forward secrecy
– Impersonation of client to server(?)
“Dos and Don’ts of Client
Authentication on the Web”
(Fu, et al.)
Authentication using “cookies”
 “Single sign-on” for users accessing a site
 Full-fledged key-exchange not practical due to
limited client (and server!) computation
 No public keys, no third parties, deployability…
 Idea: use “authenticators” stored as cookies
– No client-side computation at all
 But…must do this securely!
Minimal level of security?
 Any such scheme must be secure against
“interrogative attacks”
– These are trivial to mount by legitimate users
– In contrast to eavesdropping, server impersonation, and
man-in-the-middle attacks that are more difficult
 Confidentiality is an orthogonal issue…
 Fine-grained vs. coarse-grained authentication
– Does the system care who the user is, or just that they
are legitimate?
Security model?
 Existential forgery vs. selective forgery
– The former may typically be sufficient; the latter is
worse
 (Essentially) adaptive chosen-message attack
– User can sign up for different account under different
names, with different levels of service
 Want no existential forgery even after adaptive
chosen-message attack
– We have seen this before!
Security “hints”…
 Use appropriate amount of security
– Do you need fine-grained knowledge of the user-id or
not?
– Is confidentiality, etc. required or not?
 Use published schemes…
 No security through obscurity…
 Use cryptographic tools appropriately
Example…
 Using crypt( ) as a hash or MAC…
– Output of crypt only depends on the first 8 characters of
its input
– crypt(username | key) provides no protection if the
username is 8 characters long!
– crypto(user | key) = crypt(user’ | key) if the first 8 chars
of user match the first 8 chars of user’
– How can you determine the 8 character key using an
adaptive chosen-message attack and ~211 work?
More “hints”
 Be careful of composing security schemes
– E.g., using same key for two purposes or schemes
– E.g., different authentication schemes for account
management and purchasing; break in one allowed
recovery of password for the other
 Protect user passwords
– Don’t send in the clear, or include in URL
– Only let cookies be sent over SSL
– Re-authenticate before changing password
 Avoid predictable session identifiers
 Expiration…
A simple and secure approach…
 Use secure MAC!
 Compute MAC over entire cookie
 Cookie = (username/data, expiration, MAC)