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

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

3. 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?)

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

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

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

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

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

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