CMSC 414 Computer and Network Security Lecture 17

1
CMSC 414Computer and Network SecurityLecture 17

• Jonathan Katz

2
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

3
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

4
Mediated authentication (using a KDC)
5
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 cant
  determine KAB
• Other drawbacks
• KDC has to initiate session with Bob
• Alices message to Bob may arrive before KDCs
  message to Bob

6
Improvement

• Have KDC send to Alice the encryption of KAB
  under Bobs key
• Reduces communication load on KDC
• Resilient to message delays in network
• Bob and Alice follow with mutual authentication
  and key exchange

7
Needham-Schroeder

• A?KDC N1, Alice, Bob
• KDC?A KAN1, Bob, KAB, ticket, where ticket
  KBKAB, Alice
• A?B ticket, KABN2
• B?A KABN2-1, N3
• A?B KABN3-1

8
Analysis?

• N1 assures Alice that she is talking to KDC
• Prevents key-replay helps prevent attack when
  Bobs 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 Alices 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

9
Otway-Rees

• A?B N, Alice, KANA, N, Alice, Bob
• B?KDC KANA, N, Alice, Bob,
  KBNB, N, Alice, Bob
• KDC?B N, KANA, KAB, KBNB, KAB
• B?A KANA, KAB
• A?B KAB(timestamp)

10
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

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

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

13
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 clients password
• Forward secrecy
• Impersonation of client to server(?)

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

16
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?

17
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!

18
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

19
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?

20
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
• Dont 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

21
A simple and secure approach

• Use secure MAC!
• Compute MAC over entire cookie
• Cookie (username/data, expiration, MAC)