Nothing in this appendix is exam material. It gives simplified message flows and supporting calculations for the protocols described in the notes. Optional fields and encoding details are omitted.

The Otway-Rees Protocol

Otway and Rees published this protocol in 1987 to establish freshness without synchronized clocks. Alice starts a run with a random run identifier \(M\). Both Alice and Bob send nonces to Trent, each encrypted under its own long-term key, and Trent’s reply to each party includes that party’s nonce:

1. \(A \rightarrow B: M, A, B, \lbrace r_A, M, A, B \rbrace_{K_A}\)

2. \(B \rightarrow T: M, A, B, \lbrace r_A, M, A, B \rbrace_{K_A}, \lbrace r_B, M, A, B \rbrace_{K_B}\)

3. \(T \rightarrow B: M, \lbrace r_A, K_{AB} \rbrace_{K_A}, \lbrace r_B, K_{AB} \rbrace_{K_B}\)

4. \(B \rightarrow A: M, \lbrace r_A, K_{AB} \rbrace_{K_A}\)

Trent decrypts both protected parts of message 2 and checks that \(M\), \(A\), and \(B\) agree with each other and with the outer fields. Bob checks his nonce in message 3, and Alice checks hers in message 4, so each can connect the returned key to its own request. Neither needs a clock. Implementations must also distinguish message types and field boundaries so that a block from one message cannot be misread as another.

Neither party learns from the protocol that the other actually holds \(K_{AB}\). The first protected message each receives serves that purpose.

Kerberos Version 5 Messages

The notes describe Kerberos in three exchanges. The simplified version 5 flow below includes pre-authentication, in which the workstation proves it holds \(K_A\) by encrypting the current time before the AS replies. This stops an attacker from requesting a reply encrypted under any user’s key and guessing that user’s password offline. It does not stop offline guessing by an attacker who captures a real login, because the encrypted timestamp and the AS reply can both be used to test password guesses. Here, \(K_A\) is Alice’s password-derived key, \(K_{TGS}\) is the ticket-granting server’s key, \(K_S\) is the key of service \(S\), and \(n_1\) and \(n_2\) are nonces.

Authentication service exchange. Alice’s workstation obtains a ticket-granting ticket in two messages:

1. AS-REQ: Alice’s name, the TGS name, requested ticket times, \(n_1\), and the pre-authentication data \(\lbrace t \rbrace_{K_A}\).

2. AS-REP: the TGT \(\lbrace A, K_{A,TGS}, \text{times} \rbrace_{K_{TGS}}\), and \(\lbrace K_{A,TGS}, n_1, \text{times}, TGS \rbrace_{K_A}\).

The TGT is sent alongside the part encrypted for Alice, not inside it. Alice checks that \(n_1\) matches her request.

Ticket-granting service exchange. Alice obtains a ticket for service \(S\) in two more messages:

1. TGS-REQ: the TGT, an authenticator \(\lbrace A, t \rbrace_{K_{A,TGS}}\), the name \(S\), and \(n_2\).

2. TGS-REP: the service ticket \(\lbrace A, K_{A,S}, \text{times} \rbrace_{K_S}\), and \(\lbrace K_{A,S}, n_2, \text{times}, S \rbrace_{K_{A,TGS}}\).

Client-server exchange. Alice authenticates to the service in the last two:

1. AP-REQ: the service ticket and an authenticator \(\lbrace A, t \rbrace_{K_{A,S}}\).

2. AP-REP, sent only if Alice asks for mutual authentication: \(\lbrace t \rbrace_{K_{A,S}}\).

Version 4 returned \(t + 1\) and placed the TGT inside the part encrypted for Alice. Version 5 dropped both. Its cryptographic encoding distinguishes an authenticator from a server reply, preventing reflection even though both contain \(t\).

The client or service can also propose a sub-session key for that connection. This key is transported under the existing session key, so it is not hidden from a KDC that knows that key and records the exchange. It does not provide forward secrecy against KDC compromise.

The TLS 1.3 Key Schedule

TLS 1.3 derives keys through the HMAC-based Extract-and-Expand Key Derivation Function (HKDF). Extract combines input keying material with a salt to produce a pseudorandom key. Expand derives output from that key, with labels and context values separating outputs used for different purposes.

For an ephemeral Diffie-Hellman handshake, the main stages are:

1. The early secret comes from a pre-shared key, or zeros when no pre-shared key is used. Resumption-based 0-RTT keys come from this stage.

2. The handshake secret combines a value derived from the early secret with the new Diffie-Hellman shared secret. Separate client and server handshake traffic secrets incorporate the transcript through ServerHello. Keys derived from them protect the remaining handshake messages.

3. The master secret is derived from the handshake secret through another derivation and extraction step. Initial application traffic secrets incorporate the transcript through the server’s Finished message. Each direction’s keys are derived from its traffic secret.

Each direction gets its own key and initialization vector (IV). Transcript hashes bind the traffic secrets to the exchange. During a long connection, either side can update its sending keys by deriving a new traffic secret from its current one. This update limits use of each key but does not recover security if an attacker already knows the current traffic secret.

HOTP Truncation

HOTP computes \(\operatorname{HMAC\text{-}SHA1}_K(c)\), which produces 20 bytes, and reduces it to a short decimal code in four steps:

1. Take the low four bits of the last byte as an offset \(o\), between 0 and 15.

2. Take the four bytes starting at byte \(o\).

3. Clear the top bit, giving a 31-bit integer. This avoids differences in how signed integers are handled.

4. Reduce the integer modulo \(10^d\), where \(d\) is the number of digits, usually 6.

The specification’s test key is the ASCII string 12345678901234567890. For counter value 1, the HMAC is:

75a48a19d4cbe100644e8ac1397eea747a2d33ab

The last byte is ab, whose low four bits are b, so \(o = 11\). The four bytes starting at byte 11 are c1397eea. With the top bit cleared, that is 1,094,287,082 in decimal. Modulo \(10^6\), the code is 287082.

TOTP applies the same computation with \(c = \lfloor \text{Unix time} / 30 \rfloor\).

Lecture 4: Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Appendix
Lecture 4 Study Guide | List of terms