Outline

• Finish IPSec
• HW Problem
• Kerberos

IPSec -- the story so far

• IPSec has two parts:
• IKE: Internet Key Exchange
  • Mutual authentication
  • Establish session key
  • Two "phases" -- like SSL session/connection
• ESP/AH
  • ESP: Encapsulating Security Payload -- for encryption and/or integrity of IP packets
  • AH: Authentication Header -- integrity only
• We said there were four key options for IKE Phase 1 and two modes main and aggressive.
• We went over these two modes for public key signatures and in the symmetric key case.

IKE Phase 1: Public Key Encryption (Main Mode)

• `CP =` crypto proposed, `CS =` crypto selected
• `IC =` initiator "cookie", `RC =` responder "cookie"
• `K = h(IC,RC,g^(ab) mod p,R_A,R_B)`
• `SKEYID = h(R_A, R_B, g^(ab) mod p)`
• `pr\o\of_A = h(SKEYID,g^a mod p,g^b mod p,IC,RC,CP,"Alice")`

IKE Phase 1: Public Key Encryption (Aggressive Mode)

• `K, pro\of_A, pro\of_B` computed as in main mode
• Note that identities are hidden.
• This is the only aggressive mode in IKE to hide identities
• So, why have a main mode?

Public Key Encryption Issue?

• In public key encryption, aggressive mode...
• Suppose Trudy generates
  • Exponents `a` and `b`
  • Nonces `R_A` and `R_B`
• Trudy can compute "valid" keys and proofs: `g^(ab) mod p`, `K`, `SKEYID`, `pro\of_A` and `pro\of_B`
• This also works in main mode

Public Key Encryption Issue?

• Trudy can create exchange that appears to be between Alice and Bob
• Appears valid to any observer, including Alice and Bob!

Plausible Deniability

• Trudy can create "conversation" that appears to be between Alice and Bob
• Appears valid, even to Alice and Bob!
• A security failure?
• In this IPSec key option, it is a feature...
  Plausible deniability: Alice and Bob can deny that any conversation took place! In some cases it might create a problem
• In some cases it might create a problem
  E.g., if Alice makes a purchase from Bob, she could later repudiate it (unless she had signed)

IKE Phase 1 Cookies

• IC and RC -- cookies (or "anti-clogging tokens") supposed to prevent DoS attacks. They are not related to Web cookies
• To reduce DoS threats, Bob wants to remain stateless as long as possible
• But Bob must remember CP from message 1 (required for proof of identity in message 6)
• Bob must keep state from 1st message on
• So, these "cookies" offer little DoS protection

IKE Phase 1 Summary

• Result of IKE phase 1 is
  • Mutual authentication
  • Shared symmetric key
  • IKE Security Association (SA)
• But phase 1 is expensive
  • Especially in public key and/or main mode
• Developers of IKE thought it would be used for lots of things -- not just IPSec
  • This partly explains the over-engineering...

IKE Phase 2

• Phase 1 establishes IKE SA
• Phase 2 establishes IPSec SA
• Comparison to SSL
  • SSL connections are like IKE Phase 2
• IKE could be used for lots of things...
• ...but in practice, it's not!

IKE Phase 2

• Key K, IC, RC and SA known from Phase 1
• Proposal CP includes ESP and/or AH
• Hashes 1,2,3 depend on `SKEYID`, `SA`, `R_A` and `R_B`
• Keys derived from `KEYMAT = h(SKEYID,R_A,R_B,junk)`
• Recall SKEYID depends on phase 1 key method
• Optional PFS (ephemeral Diffie-Hellman exchange)

IPSec

• After IKE Phase 1, we have an IKE SA
• After IKE Phase 2, we have an IPSec SA
• Both sides have a shared symmetric key
• Now what? We want to protect IP datagrams
• But what is an IP datagram? Considered from the perspective of IPSec...

IP Review

• An IP datagram has the format:
  
• Here in turn an IP header looks like:
  

IP and TCP

• Consider Web traffic, then:
  • IP encapsulates TCP and...
  • ...TCP encapsulates HTTP
• IP data includes TCP header, etc.

IPSec Transport Mode

• Transport mode designed for host-to-host
• Transport mode is efficient -- Adds minimal amount of extra header
• The original header remains -- Passive attacker can see who is talking

IPSec Host-to-Host

• IPSec transport mode
• There may be firewalls in between Alice and Bob If so, is that a problem?

IPSec Tunnel Mode

• IPSec Tunnel Mode
  
• Tunnel mode for firewall-to-firewall traffic
• Original IP packet encapsulated in IPSec
• Original IP header not visible to attacker
  • New IP header from firewall to firewall
  • Attacker does not know which hosts are talking

IPSec: Firewall-to-Firewall

• IPSec tunnel mode
  
• Local Networks Not Protected
• Is there any advantage here?

Comparison of IPSec Modes

• Transport Mode -- Host-to-host
• Tunnel Mode -- Firewall-to-firewall
• Transport Mode not necessary ...
• ...but it's more efficient

IPSec Security

• What kind of protection?
  • Confidentiality?
  • Integrity?
  • Both?
• What to protect?
  • Data?
  • Header?
  • Both?
• ESP/AH do some combinations of these

HW Problem

Exercise 10.2. Consider the SSH protocol we gave earlier:

One variant of the protocol allows us to replace Alice's certificate, `c\e\r\t\i\f\i\c\a\t\e_A`, with Alice's password, `p\a\s\s\w\o\r\d_A`. Then we must also remove `S_A` from the final message. This modification yields a version of SSH where Alice is authenticated based on password.

(a) What does Bob need to know so that he can authenticate Alice?

Answer. Alice sends "Alice" and her password encrypted using `K`. So Bob needs to know `g, p`, `g^a mod p` as wells as his `g^b mod p` in order to compute `K = g^(ab) mod p` to decrypt these pieces of information. Then he must look up Alice in his password file and check her password against what he thinks is her password.

(b) Based on Problem 1, part c, Trudy can establish a shared symmetric key `K` with Alice. Assuming this is the case, can Trudy then use `K` to determine Alice's password?

Answer. No. In the next to last message Alice would receive `g^t mod p`, `c\e\r\t\i\f\i\c\a\t\e_B`, `[H_b]_(Bob)` where `h` is: `H_b = h(Alice,Bob,CP,CS,R_A,R_B,g^t mod p,g^b mod p,g^(bt) mod p)`
However, she is expecting `[H_a]_(Bob)`:
`H_a = h(Alice,Bob,CP,CS,R_A,R_B,g^a mod p,g^t mod p,g^(at) mod p)`
So she would never send the last message.

(c) What are the significant advantages and disadvantages of this version of SSH?

Answer. This version would be faster to compute for Alice (doesn't need to calculate S_A) and she doesn't have to have a certificate. For Bob though it means he must maintain a password file.

AH vs ESP

• AH -- Authentication Header
  • Integrity only (no confidentiality)
  • Integrity-protect everything beyond IP header and some fields of header (why not all fields?)
• ESP -- Encapsulating Security Payload
  • Integrity and confidentiality both required
  • Protects everything beyond IP header
  • Integrity-only by using NULL encryption

ESP's NULL Encryption

• According to RFC 2410
  • NULL encryption "is a block cipher the origins of which appear to be lost in antiquity"
  • "Despite rumors", there is no evidence that NSA "suppressed publication of this algorithm"
  • Evidence suggests it was developed in Roman times as exportable version of Caesar's cipher
  • Can make use of keys of varying length
  • Null(P,K) = P for any P and any key K
• Bottom line: Security people can be strange

Why Does AH Exist? (1)

• Cannot encrypt IP header
  • Routers must look at the IP header
  • IP addresses, TTL, etc.
  • IP header exists to route packets!
• AH protects immutable fields in IP header
  • Cannot integrity protect all header fields
  • TTL, for example, will change
• ESP does not protect IP header at all

Why Does AH Exist? (2)

• ESP encrypts everything beyond the IP header (if non-null encryption)
• If ESP-encrypted, firewall cannot look at TCP header (e.g., port numbers)
• Why not use ESP with NULL encryption?
  • Firewall sees ESP header, but does not know whether null encryption is used
  • End systems know, but not the firewalls

Kerberos

• In Greek mythology, Kerberos is 3-headed dog that guards entrance to Hades.
• In security, Kerberos is an authentication protocol based on symmetric key crypto
  • Originated at MIT
  • Based on work by Needham and Schroeder
  • Relies on a Trusted Third Party (TTP)

Motivation for Kerberos

• Authentication using public keys... `N` users implies `N` key pairs
• Authentication using symmetric keys... `N` users requires (on the order of) `N^2` keys
• Symmetric key case does not scale
• Kerberos based on symmetric keys but only requires N keys for N users
  • Con: Security depends on TTP
  • Pro: No PKI is needed

Kerberos KDC

• Kerberos Key Distribution Center or KDC
  • KDC acts as the TTP
  • TTP is trusted, so it must not be compromised
• KDC shares symmetric key `K_A` with Alice, key `K_B` with Bob, key `K_C` with Carol, etc.
• And a master key `K_(KDC)` knownn only to KDC
• KDC enables authentication, session keys. -- Session key for confidentiality and integrity
• In practice, crypto algorithm is DES

Kerberos Tickets

• KDC issue tickets containing info needed to access network resources
• KDC also issues Ticket-Granting Tickets or TGTs that are used to obtain tickets
• Each TGT contains
  • Session key
  • User's ID
  • Expiration time
• Every TGT is encrypted with `K_(KDC)`
• So, TGT can only be read by the KDC

Kerberized Login

• Alice enters her password
• Then Alice's computer does following:
  • Derives `K_A` from Alice's password
  • Uses `K_A` to get `TGT` for Alice from `KDC`
• Alice then uses her TGT (credentials) to securely access network resources
• Plus: Security is transparent to Alice
• Minus: KDC must be secure -- it's trusted!

Kerberized Login

• Key `K_A` = h(Alice's password)
• KDC creates session key `S_A`
• Alices computer decrypts `S_A` and `TGT` then it forgets `K_A`
• `TGT = E("Alice", S_A, K_(KDC))`

Alice Requests "Ticket to Bob"

• REQUEST = (TGT, authenticator).
  -- authenticator = `E(ti\me\stamp, S_A)`
• REPLY = E("Bob", `K_(AB)`, ticket to Bob, `S_A`)
  -- ticket to Bob = `E("Alice", K_(AB), K_B)`
• KDC gets `S_A` from TGT to verify timestamp