CMSC 414 Computer and Network Security Lecture 18

1
CMSC 414Computer and Network SecurityLecture 18

• Jonathan Katz

2
One-way authentication

• If 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 extend to give mutual authentication

3
Authenticated Diffie-Hellman

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

4
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

5
Dos and Donts of Client Authentication on the
Web (Fu, et al.)
6
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
• Butmust do this securely!

7
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

8
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., dont use crypt( ) as a MAC

9
More hints

• Be careful of composing security schemes
• E.g., using two authentication systems
• Protect user passwords
• Dont send in the clear
• Dont include in cookie
• Re-authenticate before changing password
• Avoid predictable session identifiers
• Expiration

10
A simple and secure approach

• Cookie (username/data, expiration, MAC)

11
Mediated authentication
12
Mediated authentication

• E.g., using KDC
• Simple protocol
• Alice requests to talk to Bob
• KDC generates KAB and sends it to Alice and Bob,
  encrypted with their respective keys
• Note no authentication here, but impostor cant
  determine KAB

13
Improvement

• Have KDC send to Alice the encryption of KAB
  under Bobs key
• Reduces communication load on KDC
• Resilient to message delays in network

14
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)

15
Analysis?

• N1 assures Alice that she is talking to KDC
• Prevents key-replay, helps prevent attack when
  Bobs 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 Alices key is compromised
• Bobs ticket is always valid
• Use timestamps, or request (encrypted) nonce from
  Bob at the very beginning of the protocol