Lecture 10: Mediated Authentication

1. Lecture 10: MediatedAuthentication • simple algorithm • Needham-Schroeder • simple • expanded • Otway-Rees • nonce types

2. Establishing Session Key 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 Alice, Bob KB{Alice, KAB} KDC KA{Bob, KAB} Alice Bob

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

4. Needham-Schroeder ProtocolOutline N1, Alice, Bob KA{N1, Bob, KAB, ticketB} where ticketB= KB{KAB, Alice} KDC ticketB, KAB{N2} Bob Alice KAB{N2-1, N3} KAB{N3-1}

5. Needham-Schroeder ProtocolExplained • 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

6. 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 Trudy can separate KAB{N2-1} and KAB {N3} Bob KAB{N3-1} ticketB, KAB{N3} Trudy Bob KAB{N3-1, N4} BTW, why are N2 and N3 encrypted at all in N-S?

7. 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}

8. Otway-Rees ProtocolOutline 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} Bob Alice KA{NA, KAB} KAB{anything recognizable}

9. Otway-Rees ProtocolExplained • 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.

10. 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

11. Value of Unpredictability for Nonces • 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? I’m Alice KAB{R} Alice Bob R