CMSC 414
Computer and Network Security
Lecture 18
Jonathan Katz

One-way authentication

If only the server has a known public key
(e.g., SSL)
– Server sends R
– Client sends E pk
(R, password, session-key)

Insecure in general!!!
– But secure if encryption scheme is chosen appropriately

Can extend to give mutual authentication

Authenticated Diffie-Hellman

Add signatures/MACs and nonces to Diffie-
Hellman protocol
– Note: achieves forward secrecy
– What if we had used encryption instead?

Using session keys

Generally, want to provide both secrecy and integrity for subsequent conversation
– Use encrypt-then-MAC
– Use sequence numbers to prevent replay attacks
– Use a directionality bit
– Periodically refresh the session key

“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…
 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

Eavesdropping, server impersonation, and man-in-the-middle attacks are more difficult
 Confidentiality is an orthogonal issue…

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
– E.g., don’t use crypt( ) as a MAC…

More “hints”

Be careful of composing security schemes
– E.g., using two authentication systems…

Protect user passwords
– Don’t send in the clear
– Don’t include in cookie

Re-authenticate before changing password

Avoid predictable session identifiers
 Expiration…

A simple and secure approach…

Cookie = (username/data, expiration, MAC)

Mediated authentication

Mediated authentication

E.g., using KDC

Simple protocol:
– Alice requests to talk to Bob
– KDC generates K
AB and sends it to Alice and
Bob, encrypted with their respective keys
– Note: no authentication here, but impostor can’t determine K
AB

Improvement…

Have KDC send to Alice the encryption of
K
AB under Bob’s key
– Reduces communication load on KDC
– Resilient to message delays in network

Needham-Schroeder

A

KDC: N
1
, Alice, Bob

KDC

A: K
A
(N
1
, Bob, K
AB
, ticket), where ticket = K
B
(K
AB
, Alice)

A

B: ticket, K
AB
(N
2
)

B

A: K
AB
(N
2
-1, N
3
)

A

B: K
AB
(N
3
-1)

Analysis?

N
1 assures Alice that she is talking to KDC
– Prevents key-replay, helps prevent attack when Bob’s key is compromised and then changed
 Important: authenticate “Bob” in message 2, and
“Alice” in ticket
 Uses encryption to authenticate… 
– Leads to actual flaw if, e.g., ECB mode is used!
 Vulnerable if Alice’s key is compromised
– Bob’s ticket is always valid
– Use timestamps, or request (encrypted) nonce from Bob at the very beginning of the protocol