Graduate Course on Cryptography and Computer Security Invited Lecture on Computer Security

1
Graduate Course onCryptography and Computer
SecurityInvited Lecture on Computer Security

• Iliano Cervesato iliano_at_itd.nrl.navy.mil
• ITT Industries, Inc _at_ NRL Washington DC
• http//theory.stanford.edu/iliano/

2
Lecture Outline

• Part I
• Authentication Protocols
• Attacks
• Part II
• Case study I WEP
• How not to design a protocol
• Part III
• Case study II Kerberos V
• A flavor of formal verification

3
Part IAuthentication Protocolsand Attacks
4
Outline
Cryptography is not broken,it is
circumvented Shamir

• Authentication Protocols
• Challenge-response
• Key generation
• Key distribution
• Attacks
• Man-in-the-middle
• Type flaw
• Parallel session
• Binding
• Encapsulation
• Implementation-dependent

5
Networked Security Protocols

• Protocol
• Procedure for 2 or more agents to achieve a
  common goal
• Security
• Goal involves 1 or more of
• Confidentiality
• Authentication
• Integrity, anonymity, privacy, fair-exchange,
  non-repudiation, authorization, accountability,
  availability,
• Networked
• Electronic medium of communication
• Dedicated link (secure channel)
• Intranet (trusted channel)
• Internet (insecure channel)

6
Security Protocols

• Cryptography provides virtual trusted channels
• Security protocols
• How to establish, maintain and use these channels
• Authentication protocols
• How to establish channel in the first place
• Negotiate parameters of channel
• Ensure that channel is still trusted
• Other types of protocols
• Using trusted channels for specific purposes
• Electronic commerce (e-cash, e-auctions, )
• Electronic voting
• Electronic contract signing,

7
Authentication Protocols

• Challenge-response
• Verify somebody is at the other end of channel
• Key generation
• Establish channel
• Key distribution
• Bind channel ends with requesters
• Key translation
• Use indirect channels
• These aspects can be combined

8
Some Notation

• We abstract from the cryptographic algorithms
  used
• Encryption mk
• In particular shared-key encryption
• Public-key encryption sometimes written mk
• Authentication mk
• In particular for MACs
• Digital signatures sometimes written mk
• Usually includes both message and digest
• Decryption/verification not modeled explicitly

9
Our Heros

• Generic principals
• A (Alice)
• B (Bob)
• C (Charlie),

• Servers
• S (Sam)
• specialized names
• Trusted-Third Party TTP
• Certification Authority CA
• Key Distribution Center KDC

• Attacker
• I (intruder)
• Also known as
• E (Eve eavesdropper, enemy)
• M (Mallory malicious)
• Trudy, .

10
Challenge-Response Protocols
A
B

• Given trusted channel
• A checks if B is there
• Sends challenge to B
• Waits for response
• Get B to use the channel
• By decrypting the challenge
• By encrypting the response
• or both
• Used to
• Test a newly established channel
• Verify a previously used channel
• Usually part of bigger protocols
• Also called authentication test

Hi, its me!
Im here too!
As view
11
Guarantying Freshness

• Reusing challenges is dangerous
• Replay of favorable messages
• If channel used to transmit keys
• and a previous key k was compromised,
• then I can force A to reuse k
• Response should be fresh
• Nonces
• Timestamps
• Sequence numbers
• Fresh key (with care!)

12
Nonces

• Random sequence of bits
• Typically 32-128 bit long
• Generated fresh by originatoras challenge
• Unpredictable
• Checked in response
• Not checked by recipient
• Impractical to memorize them
• Never reused
• But may contribute to keys
• E.g. by hashing

Challenge-response exchanges using nonces
13
Timestamps

• Current time in local computer
• E.g. in milliseconds
• Checkable by recipient
• Element of predictability
• Recipient must keep most recenttimestamps to
  avoid replay
• Requires common time reference
• Allow for clock skew
• Use secure synchronized clocks
• Supports for service time-out

Challenge-response exchanges using timestamps
14
Sequence Numbers

• Originator maintains counter
• Incremented by 1 after eachchallenge
• Must be bound with data thatidentifies channel
• Recipient memorizes mostrecent value
• Rejects values that are too old
• Similar to timestamp but
• Local to originator or even channel
• Cannot be used for timeout

Challenge-response exchanges using counters
15
Keys

• Initiator generates key k
• Sends it encrypted
• Recipient responds using k
• Other mechanisms needed toguaranty freshness to
  recipient
• Often done through third-party
• Achieves key distribution at the same time

S
Challenge-response exchanges using keys
kkAS
kkBS
A
B
Hi!k
16
More on Keys

• Long-term keys
• Exist before the protocol begins
• Do not change across protocol executions
• Session keys (or short-term keys)
• Generated as part of the protocol
• Validity guaranteed till protocol is completed
• Could be released when protocol terminates
• Could be cryptographically weak
• Session (or run)
• Protocol execution from start to finish

17
Authentication

• Assurance to be talking with the expected
  principal
• Challenge-response is a fundamental mechanism
• Ensure freshness
• If channel is trusted, authenticatesrecipient to
  initiator
• Mutual authentication
• Both party believe they are talkingto each other
• Done through doublechallenge-response
• Typically 3 messages

A
B
A,nAkB
nA,nBkA
nBkB
Needham-Schroederpublic-key protocol(fragment)
18
Key Generation Protocols

• A wants to establish channel with B
• Shared-key infrastructure
• Principals shares a key with a KDC
• Public-key infrastructure
• Principals have published encryption keys
• Diffie-Hellman
• Principals know group and generator

19
with Shared-Key Infrastructure

• Each principal has ashared key with KDC S
• Ask S to create channel
• Create new key k
• Distribute k to A and B using kAS and KBS
• Examples
• Needham-Schroeder shared-key protocol
• Otway-Rees, Yahalom, Woo-Lam,

20
Needham-Shroeder Shared Key
A
S
B
A,B,nA
nA,B,kAB,kAB,AkBSkAS
kAB,AkBS
nBkAB
nB-1kAB

• S creates kAB
• 2 challenge response authenticate A and B

21
with Public-Key Infrastructure
Public data kA, kB, kC, kD

• Each principal has acertified public
  keyavailable to others
• A and B use kB and kA tocommunicate securely
• Examples
• Bilateral key exchange protocol

22
Bilateral Key Exchange Protocol
A
B
Publicdata kA, kB
A,nA,BkB
h(nA),nB,B,kkA
h(nB)k

• h is a hash function
• Certificates could be included
• Includes 2 challenge response exchanges

23
with Diffie-Hellman

• Diffie Hellman alone cannot guarantee
  authentication
• Minimum infrastructure required
• Public key infrastructure for signatures
• Examples
• Station-to-station protocol
• Found as option in many big protocols
• IPSEC, ISAKMP,

24
Station-to-Station Protocol
Publicdata p, g
A
B
ga
k gab
gb,ga,gbkBk
k gab
ga,gbkAk

• This is an authenticated Diffie-Hellman
• ga and gb used for challenge response
• Achieves mutual authentication

25
Key Distribution Protocols

• A and B possess public keys
• Registered with certification authority
• Certificates not available
• Request signed certificates from CA
• Examples
• Needham-Schroeder public-key protocol
• S acts as key database and CA
• A and B use nonces for mutual authentication

26
Needham-Shroeder Public Key
A
S
B
Publicdata kA, kB
A,B
B,kBkS
A,nAkB
B,A
A,kBkS
nA,nBkA
nBkB
27
Key Translation Protocols

• A wants to send message to B
• but no server is around to create keys
• A exploits existing channels with a trusted third
  party S
• A send m to S encrypted with kAS
• S forwards m to B encrypted with kBS
• Timestamps or other mechanisms used for
  authentication
• S must be trusted to manipulate them correctly
• Examples
• Wide-Mouthed Frog protocol

28
Wide-Mouthed Frog Protocol
A
S
B
A,tA,B,kABkAS
tS,A,kABkBS

• A generates the key kAB
• S provides trusted timestamping
• With tA, A authenticates to S
• With tS, S authenticates to B
• A authenticates to B indirectly
• No authentication in the reverse direction

29
Subprotocols

• Useful to add structure to protocols
• Deterministic choice of continuation
• Protocol behaves differently on different inputs
• Protocols responds to optional requests
• Non-deterministic continuation
• Protocol flips a coin
• Protocol can request optional behavior
• Repeated parts
• Repetitive behavior after initial phase
• E.g. Neuman-Stubblebine, Kerberos,

30
Neuman-Subblebine Initial Part
A
S
B
A,nA
B,A,nA,tBkBS ,nB
B,nA,kAB,tBkAS ,A,kAB,tBkBS ,nB
A,kAB,tBkBS,nBkAB

• A,kAB,tBkBS is As ticket to access Bs service
• nA and nB mutually authenticate A and B

31
Neuman-Stubbl. Repeated Part
A
B
A,kAB,tBkBS,nA
nB,nAkAB
nBkAB

• A uses ticket to access Bs service
• until it expires
• nA and nB reauthenticate A and B

32
Attacks

• Almost all previous protocols have flaws!

33
Lowes Attack on NS-PK
A ? B A,nAkB B ? A nA,nBkA A ? B nBkB
NS-PK 3-5
A
I
B
Publicdata kA, kB , kI
A,nAkI
A,nAkB
nA,nBkA
Attack discovered 17 years after protocol was
published
nBkI
nBkB

• (Exchanges with S have been omitted)

34
Man-In-The-Middle Attack

• A wants to talk to B
• I has replaced kB with kI in Ss database
• I acts as a key translator
• In the end
• A thinks to be talking to B, but she is talking
  to I
• B thinks to be talking to A, but he is talking to
  I
• A really wants to talk to I
• I cheats and acts as key translator
• In the end
• A knows she talking to I
• B thinks to be talking to A, but he is talking to
  I

35
What happened?

• Protocol assumptions were not specified
• Intruder is (also) a principal
• What are the intruders capabilities anyway?
• Initial knowledge of principals
• Meaning of notation
• Who can access what? How?
• Protocol goals were not specified
• Failure of mutual authentication
• but A has authenticated I
• Many people do not agree that this is an attack!

36
Protocol Specifications

• Describe what the protocol does
• For doing implementation
• For doing verification
• 3 aspects
• Assumptions
• Initial knowledge
• Maintained state
• Environment
• Intruder
• Messages exchanged
• Goals

ication
S p e c i f
37
The Dolev-Yao Intruder

• Standard attacker model
• Intercept / Emit messages
• Decrypt / Encrypt with known key
• Split / Form pairs
• Look up public information
• Generate fresh data
• Not fully realistic but convenient

38
Lowes Fix to NS-PK
A
B

• Assumptions
• Dolev-Yaointruder
• I is a principal
• Principals knowpublic data
• Public data is correct
• Private keys uncompromised

A,nAkB
Publicdata kA, kB
nA,nB,BkA
nBkB

• Goals
• Mutual authentication
• Freshness of nonces
• Secrecy of nonces

39
Millens Attack on NSL
A ? B A,nAkB B ? A nA,nB,BkA A ? B nBkB
Needham-Schroeder-Lowe
Unlikely type violation
40
Type-Flaw Attacks

• Functionalities seen as types
• Names
• Nonces
• Keys,
• Violation
• Recipient accepts message as valid
• but imposes different interpretation on bit
  sequence than sender
• Type flaw/confusion attack
• Intruder manipulates message
• Principal led to misuse data

41
The Dolev-Yao Model of Security

• An abstraction for reasoning about protocols
• Not to be confused with the Dolev-Yao intruder
  although related
• More on Dolev-Yao model later
• Data are atomic constants
• No bits
• Subject to symbolic manipulations
• Tension between type violations and Dolev-Yao
  model

01001011010
kA
42
Some Other Common Attacks

• Freshness
• I forces stale data in challenge-response
• Parallel session
• I combines messages from different sessions
• Binding
• I subverts the public database
• Encapsulation
• I uses another principal for encryption or
  decryption
• Cipher-dependent
• I exploits properties of cryptographic algorithms
  used
• and many more

43
Freshness Attacks
A ? S A,B,nA S ? A nA,B,kAB, k,nA kBSkAS A
? B kAB,AkBS B ? A nBkAB A ? B nB-1kAB
(normal run)
Needham-Schroeder Shared-Key

• I records exchange
• Replays messages in subsequent run
• kAB is a not fresh
• But B does not know
• Next messages over kAB are known to I

I discovers kAB
I
B
I
kAB,AkBS
nBkAB
nB-1kAB
44
Parallel Session Attacks
A ? B nA,T B ? A nB,nAkAB A ? B
nBkAB where T A,kAB,tBkBS
I
B
Neuman-Stubblebine phase II
nA,A,kAB,tBkBA
nB,nAkAB

• B things he has authenticated A
• A has not even participated

nB,A,kAB,tBkBA
nB,nBkAB
nBkAB

• I combines messages from 2 sessions

45
Binding Attacks
A ? S A,B,nA S ? A S,S,A,nA,kBkS
A
I
S
A,B,nA

• I convinces A that Bs public key is kI

A,I,nA
S,S,A,nA,kIkS

• I overwrites replies from CA
• I may also overwrite public tables

46
Encapsulation Attacks
A ? B B,mkAS B ? S B,mkAS,A S ? B m,AkBS
I
B
Davis-Swick
B,(A,m)kIS
S
B,(A,m)kIS,I
A
(A,m),IkBS
A,(m,I)kBS
A,(m,I)kBS,B
(m,I),BkAS

• A believes message (m,I) comes from B
• m may include key material

• I uses other principals as cryptographic oracles

47
Cipher-Based Attacks
A ? S A,B,nA S ? A nA,B,k, kAB,nA
kBSkAS A ? B kAB,AkBS B ? A nBkAB A ? B
nB-1kAB
A
S
A,B,nA
Needham-Schroeder Shared-Key
nA, B, kAB,kAB, AkBS kAS

• Prefix of CBC is valid
• Here also
• Parallel session
• Type flaw

nA, BkAS

• I exploits particular cipher in use
• I exploits implementation of cipher

48
Black-Box Cryptography
Most attacksare independentfrom details
ofcryptography

• Another aspect of Dolev-Yao model
• No first-class notion of ciphertext
• mk is a term
• m accessible in mk only if k is known
• No guessing of bits
• Bridging the gap between
• cryptographic algorithms and
• Dolev-Yao model
• Several proposal, no definite solution
• Not covered lecture

49
Further Issues

• Mixing protocols
• Protocols may appear safe in isolation
• but have nasty interactions when mixed
• Several protocols coexist in a system
• Composing protocols
• In parallel
• In sequence
• Modularity would help
• Little composability
• Recent progress

50
Getting Protocols Right

• Testing
• Not a solution!
• Assumes statistical distribution of errors
• Security is about worst-case scenario
• Formal verification
• Attack-free construction
• Rules-of-thumb
• Formal criteria
• A few automated tools

51
Readings

• D. Gollmann Authentication Myths and
  Misconception, 2001
• J. Clark, J. Jacob A Survey of Authentication
  Protocol Literature Version 1.0, 1997 www
• D. Dolev, A. Yao On the security of public-key
  protocols, IEEE TIT, 1983.
• R. Needham, M. Schroeder Using Encryption for
  Authentication in Large Networks of Computers,
  CACM, 1978 www

52
Exercises for Part I

• Find a parallel session attack on the handshake
• A ? B nAkAB
• B ? A nA1kAB
• Fix the key distribution protocol on slides 44
• Find a type flaw attack on the Yahalom protocol
• A ? B A,nA
• B ? S B,A,nA,nBkBS
• S ? A B,kAB,nA,nBkAS,A,kABkBS
• A ? B A,kABkBS,nBkAB

53
Part II802.11 andWired Equivalent Privacy
54
Outline

• The 802.11 wireless communication standard
• WEP Wired Equivalent Privacy
• Architecture
• Security goals
• Attacks
• Confidentiality
• Authentication
• Integrity
• Lessons Learned

55
The IEEE 802.11 Standard

• Specifies standard networking functions over
  radio waves
• Transparent layer for upper network protocols
  (IP, TCP, Novell NetWare, )
• Implements wireless networks (WLAN)
• Integrates seamlessly into a LAN
• Works on any platform, given drivers
• Fast up to 11Mbit/s
• Ethernet is 10Mbit/s, fast Ethernet 100Mbit/s
• Range about 30m/100feet
• Widely deployed
• PCMCIA cards, ISA bus cards, embedded solutions,
  
• Offered by major vendors

56
Infrastructure Mode
Wired network
Access Point(AP)
Mobilestation

• Access points connect to wired network
• Multiple mobile stations per AP
• Full internet connection for mobile users
• University campus
• Coffee shops
• airport lounges,

57
Ad Hoc Mode

• Wireless stationscommunicate directly
• Communication withouta wired network
• On the fly networking
• Impromptu meeting
• LAN set up is difficult
• Monitoring volcanoes
• Study of jungle canopy
• LAN set up is dangerous
• War zones

58
Data Transmission

• For both LANs and WLANs
• Communication broken into frames
• Variable length (up to 1,500 byte)
• Header associated with frame
• Source address
• Destination address
• Frame length,
• Packet header frame

59
Subverting Communication

• WLAN
• Eavesdropping
• Hardware widely sold
• Proximity of source
• Parking lot attack
• Injecting traffic
• Just send to network
• May need to modify driver setup
• Removing traffic
• Scramble radio signal

• LAN
• Eavesdropping
• Plug in laptop
• Need access to wire
• Hardly unnoticeable
• Injecting traffic
• Just send to network
• May need to modify driver setup
• Removing traffic
• Feasible

60
WEP Wired Equivalent Privacy

• Security mechanism for WLANs
• 2 subsystems
• Station authentication
• Simulate wired access control
• Data encapsulation
• Create privacy of wired network
• Part of 802.11 standard

61
WEP Authentication
AP
Hi, its me
S
n
n ? RC4(k)
k distributed out of band

• S and AP share key k
• 802.11 standard 40 bit
• Most vendors now offer 104 bits (advertised as
  128 bit!)
• n is randomly generated nonce
• S is accepted only if last message decrypts to n

62
Data Encapsulation

• A wants to send frame m to B
• Encapsulation (A)
• Compute CRC-32 integrity checksum cm of m
• Public algorithm, does not depend on k
• Compute keystream RC4(k,v)
• RC4 is secure keystream function (proprietary
  RSA)
• v is 24 bit initialization vector (IV)
• Broadcast v,x v, ((m cm) ? RC4(k,v))
• Decapsulation (B)
• x ? RC4(k,v)) m cm

63
Pictorially

• Checksum guarantees data integrity
• IV
• Prevents reuse of keystream
• WEP does not prescribe modification of IVs
• Sent with each packet

64
WEP Security Goals

• Confidentiality
• Prevent eavesdropping
• Access control
• Prevent unauthorized access
• Integrity
• Prevent tempering with messages

WEP does not achieve any of them!
65
Keystream Reuse

• WEP collision
• If x1 ((m1 cm1) ? RC4(k,v))and x2 ((m2 cm2)
  ? RC4(k,v))
• Then x1 ? x2 (m1 cm1) ? (m2 cm2)
• Independent from key length!
• Recognizing collisions
• k changes very seldom, if ever
• Generally, all stations use same k
• v sent in clear with every packet
• Look for packets with the same IV

66
Likelihood of Keystream Reuse
Given r1, rn ? 0, 1, , B If n ? 1.2?B,then
Prob? i ? j ri rj gt ½

• Ideal case
• By birthday paradox
• 50 chances of collision after 5000 packets
• lt 4 minutes at 5Mbit/s (packets of 1500 bytes)
• All 224 keystreams recovered in ½ day
• In practice, IVs are poorly generated
• Many PCMCIA cards
• IV0 when inserted
• incremented by 1 at each packet
• Few thousand IVs determine most traffic
• 802.11 does not require changing IV

67
Attacks
If x1 ((m1 cm1) ? RC4(k,v))and x2 ((m2 cm2)
? RC4(k,v)) then x1 ? x2 (m1 cm1) ? (m2 cm2)

• Passive attacks
• Exploit message redundancy
• Many fields of IP header are predictable
• Login sequences (e.g. Password )
• Transfer of shared libraries,
• Active attacks
• Send spam to mobile host
• Have mobile host send you email,
• Dumb attacks
• Some APs send frames unencrypted also

68
Decryption Dictionaries

• Once packet is revealed, keystream is known
• Build table of intercepted keystreams
• Maps every v to RC4(k,v))
• Requires 24Gb for 224 1,500 byte frames
• Less than 1Gb with PCMCIA IV generation
• Then, can decrypt all traffic

69
Key Management

• 802.11 does not specify how to
• Generate
• Distribute
• Update shared key (and how often)
• In practice
• Key is loaded in device by hand when set up
• Often keep manufacturers default
• Never updated again
• Attacker has years to compromise key
• A few hours are enough for 40 bit version

70
Restoring Confidentiality

• IV is too short
• Collisions frequency reduced with longer IVs
• Relatively small decryption dictionary
• IV update unspecified (and not required)
• Force collision resistant IV generation
• From keyed random number generator
• Key management inexistent
• Introduce mandatory key update protocol
• Force different key for each host

71
Gaining Access
Hi, its me
n
n ? RC4(k)

• Trivial !
• Record one authentication exchange
• from (n, n ? RC4(k)), recover RC4(k)
• Use it to encrypt all future authentication
  challenges
• Remedy
• Use different cipher for authentication
• A block cipher would do

72
Perturbing Traffic

• Integrity protected by CRC-32 checksum
• Checksums are linear w.r.t. ?
• cm?m cm ? cm
• Then for any D, xoring any ciphertext x with(D
  cD) will go undetected
• Remedy
• exercise

73
Targeted Traffic Alteration

• Linearity of CRC limited to flipping bits
• Use format of frames to force bit values
• E.g. IP header
• Build decryption dictionary

74
Analysis of a Débacle

• Why is WEP so bad??
• International standard
• Backed by big vendors (IBM, 3COM, Apple, )
• Written by communication engineers
• Keep packet length small
• Be conservative in what you send, liberal in
  what you accept
• Not security people involved
• Opaque design (no public review before
  standardization)
• Could have profited from IPSec experience
• Should operate with limited resource
• Cell phones, PDAs,

75
The Future of WEP

• Proposal for a new standard 802.1X
• Use stream cipher based on AES
• Sequence number to avoid replays
• Replace CRC with MAC
• Authentication based on Kerberos

76
Should You Go Wireless?

• YES!
• 802.11 is a fine communication suite
• Handle security at higher levels
• Virtual Private Network (VPN)
• IPSec
• or just what younormally use!

77
Readings

• N. Borisov, I. Goldberg and D. Wagner
  Intercepting Mobile Communications the
  Insecurity of 802.11, 2001 www
• W. Arbaugh, N. Shankar, and Y. Wan Your 802.11
  Wireless Network has no Clothes, 2001 www
• IEEE 802.11 Working Group web page,
  http//grouper.ieee.org/groups/802/11
• J. Walker Overview of 802.11 Security, 2001
  www

78
Exercises for Part II

• Prove that
• if x ((m cm) ? RC4(k,v)),
• Then x ? (D cD) has a correct checksum for every
  D
• Suggest a remedy for traffic perturbation

79
Part IIIKerberos V andFormal Protocol
Verification
80
Lecture Outline

• Security protocol verification
• Kerberos 5
• Main exchange
• Verification of Kerberos 5
• Authentication properties
• Anomalies

81
Security Protocol Verification

• P Formal protocol specification
• E Environmental assumptions
• S Security requirements
• E ? P ? S
• Difficulties
• Subtle cryptographic primitives
• Dolev-Yao abstraction
• Distributed hostile environment
• Needhams Prudent engineering practice
• Inadequate specification languages
• Huge improvements in the last 5 years

Typical verificationproblem
82
Correctness vs. Security Mitchell

• Correctness satisfy specifications
• For reasonable inputs,get reasonable output
• Security resist attacks
• For unreasonable inputs,output not completely
  disastrous
• Main difference
• Active interference from the environment

83
Verification Techniques (1)

• Model checking
• Most tools (NPA, CAPSL, Athena, Murf, )
• Visit bounded (symbolic) state space
• Forward from initial configuration to undesired
  state
• Backward from attack state to initial
  configuration
• Can find attacks but not positive security
  results
• Highly automatable

84
Verification Techniques (2)

• Epistemic logics
• BAN, GNY, SvO,
• Reasons about mutual belief of principals
• A believes B believes A sent A, NAKB recently
• Went out of fashion, but recent revival

85
Verification Techniques (3)

• Theorem proving
• Paulsons method,
• Also, this work
• Inductive characterization of valid traces
• Guarantees security, but does not find attacks
• Very labor-intensive

86
Verification Techniques (4)

• Process equivalence
• Spi calculus,
• Security reduced to process equivalence
• For all M, prot(M) ? spec (M)
• Useful conceptual tool
• No automation, ever?

87
Verification Techniques (5)

• Light weight symbolic methods
• CRYPTYC
• Type annotations
• Security reduces to typechecking
• Fully automatic, relatively easy to use
• Related approaches (loosely)
• Strand authentication tests
• security constraints

88
Verification Work on Kerberos

• Kerberos 4
• Analyzed using inductive approach
• Bella Paulson
• Use Isabelle/HOL theorem prover
• Kerberos 5
• Simplified version analyzed
• Mitchell, Mitchell Stern
• Use Murf model checker
• Detailed specification and verification
• Butler, Cervesato, Jaggard Scedrov
• MSR framework and theorem proving

89
Kerberos Principals
Login shell,Printer,
User,applet,
90
Kerberos 5

• Repeatedly authenticate client C to server S
• Like Neuman-Stubblebine, but 2 levels
• C obtains long term (eg, 1 day) ticket from KAS
• Makes use of Cs long term key
• Ticket encrypted unreadable by C
• C obtains short-term (eg 5 min) ticket from TGT
• Based on long term ticket from KAS
• C sends this ticket to S

91
Main Kerberos Exchange
92
Abstract and Detailed Messages
93
Abstract Authentication Theorem

• If T receives the message
• kCT,CkT, CkCT,C,S,n2
• then some K created kCT and sent
• C,kCT,CkT, kCT,n1,TkC
• and C sent some
• X,CkCT,C,S,n2
• In Kerberos 4
• C must have sent the ticket and not generic X
• Similar result for Client/Server exchange
• Ticket came from T, authenticator from C

94
Detailed Authentication Theorem

• Add details to obtain theorem for detailed
  formalization
• Structure of abstract level proof remains
• Just add details
• If T processes the message
• TFlags,kCT,CkT, C,ck,tkCT,TOpts,C,S,n2,e
• then some K created kCT and sent
• C,TFlags,kCT,CkT, kCT,n1,TFlags,TkC
• and C sent some
• X,C,ck,tkCT,TOpts,C,S,n2,e
• with
• ck TOpts,C,S,n2,ekCT

95
Anomalies

• Interesting curiosities, but dont appear
  dangerous
• Weve just seen that authentication does hold
• Encryption type anomaly
• Difficult to recover from lost long term key
• Ticket switch anomaly
• Client has incorrect beliefs about data in her
  possession
• Application to anonymous tickets
• Anonymous option under review by Working group
• Ticket option anomaly
• Effects similar to ticket switch anomaly

96
Encryption Type Anomaly

• Kerberos 5 allows C to specify encryption types
  that she wants used in Ks response
• Cs key of etype ebad is kbad
• Intruder learns kbad
• C knows this and attempts to avoid ebad/kbad
• I can still force kbad to be used

97
Ticket Anomaly

• Kerberos 4
• Ticket is enclosed in another encryption
• Kerberos 5
• Ticket is separate from other encryption

C
K
98
Ticket Anomaly
99
Ticket Anomaly

• T grants C a ticket for S
• C has never sent a proper request for a ticket
• C never has the ticket for T
• C thinks she has sent a proper request
• Cs view of the world is inaccurate
• Some properties of Kerberos 4 dont hold here
• Seen in both formalizations
• Variations possible using added detail
• Anonymous tickets

100
Ticket Option Anomaly

• C obtains tickets ST and ST with different
  options for use with same server S
• C does not request mutual authentication from S
• No response expected
• Assume that S can detect replays
• Saves authenticators in a cache (following RFC
  1510)

101
Ticket Option Anomaly
102
Ticket Option Anomaly

• Cs request at time t is accepted, but her
  request at time t is never seen by S
• C sees an error message with the timestamp t
• Might assume request at t not accepted, request
  at t accepted
• I uses the replay to unpack the encrypted
  timestamp t
• Ss use of a replay cache allows this to occur
• Effects are similar to those of ticket switch
  found before but for more ticket options
• Replay cache not yet formalized

103
References

• C. Neuman, J. Kohl, T. T'so, K. Raeburn, T. Yu
  The Kerberos Network Authentication Service
  (V5), ongoing www
• F. Butler, ic, A. Jaggard, A. Scedrov A Formal
  Analysis of Some Properties of Kerberos 5 Using
  MSR, CSFW 2002 www
• G. Bella, L. Paulson Using Isabelle to Prove
  Properties of the Kerberos Authentication
  System, 1997 www
• S. Schneider Verifying Authentication Protocols
  in CSP, 1998 www