Lecture 10: Mediated Authentication simple algorithm Needham-Schroeder simple expanded Otway-Rees nonce types

Establishing Session Key Alice, Bob KB{Alice, KAB} KDC KA{Bob, KAB} Alice Bob problem (besides others): Bob will not know how to decrypt a message from Alice if message from KDC is late establishing connection KDC <-> Bob is (somewhat) expensive

Establishing Session Key (variant) Alice, Bob KA{Bob, KAB}, ticketB where ticketB= KB{Alice, KAB} KDC Alice Bob Alice, ticketB Problems: no authentication between Alice and Bob no freshness guarantee for KAB (what if Alice reuses the ticket?)

Needham-Schroeder Protocol Outline N1, Alice, Bob KA{N1, Bob, KAB, ticketB} where ticketB= KB{KAB, Alice} KDC ticketB, KAB{N2} Alice Bob KAB{N2-1, N3} KAB{N3-1}

Needham-Schroeder Protocol Explained N1 is for KDC authentication to ensure freshness of KAB attack (without nonce): Trudy stole KAB from Bob and records old KDC’s reply to Alice; Trudy waits for a new request to KDC form Alice to talk to Bob and plays back old KDC’s reply impersonating KDC Reply from KDC strings “Bob” and “Alice” disallows Trudy tampering with messages and hijacking the conversation N2, N3: for key confirmation and mutual authentication (minor) issue: ticket is unnecessarily doubly encrypted in message from KDC

Needham-Schroeder: Reflection Attacks If message integrity is vulnerable (for example with ECB), reflection attack is possible replay ticketB, KAB{N2} KAB{N2-1, N3} Trudy can separate KAB{N2-1} and KAB {N3} Trudy Bob KAB{N3-1} ticketB, KAB{N3} BTW, why are N2 and N3 encrypted at all in N-S? otherwise reflection attack is even easier Trudy Bob KAB{N3-1, N4} BTW, why are N2 and N3 encrypted at all in N-S?

Expanded Needham-Schroeder in standard N-S, Bob doesn’t have freshness guarantee for KAB (i.e., can’t detect replays) to fix – get a nonce form Bob hello KB{NB} N1, Alice, Bob, KB{NB} KA{N1, Bob, KAB, ticketB} where ticketB= KB{KAB, Alice, NB} KDC Alice Bob ticketB, KAB{N2} KAB{N2-1, N3} KAB{N3-1}

Otway-Rees Protocol Outline NC, “Alice”, “Bob”, KA{NA, NC, “Alice”, “Bob”} KA{NA, NC, “Alice”, “Bob”} KB{NB, NC, “Alice”, “Bob”} KDC NC, KA{NA, KAB}, KB{NB, KAB} Alice Bob KA{NA, KAB} KAB{anything recognizable}

Otway-Rees Protocol Explained NA, NB: Provides freshness guarantee for A & B, as well as authentication of KDC. NC: To bind Alice, Bob, and the session. having separate NA and NC is not necessary for security, though it’s good for functional separation of nonces and uniformity of KDC messages.

Nonce Types nonce: a quantity which any given user of a protocol uses only once (a quantity which is guaranteed fresh) nonce types: sequence numbers need to keep state, what if Trudy can induce crashes (DoS attack?) timestamps need synchronized clocks random numbers freshness guarantee is only probabilistic but if number is large it is good enough unpredictable

Value of Unpredictability for Nonces I’m Alice KAB{R} Alice Bob R recall the one one-way authentication alg is there a problem if R is a sequence number? what if Alice sends the plaintext challenge first and Alice replies with encrypted challenge? what if timestamps are used for challenges? is there a problem if R is a sequence number? yes, Trudy can eavesdrop on previous session and predict R what if Bob sends encrypted challenge first? still a problem: Trudy can predict what the next challenge from Bob will be, request Alice to encrypt it and impersonate Alice to Bob what if timestamps are used for challenges? still a problem if timestamp granularity is low (seconds?) – trudy can attempt to guess a timestamp