Proof Methods for an MSR Analysis of Kerberos 5

1. Proof Methods for an MSR Analysis of Kerberos 5 Frederick Butler, Iliano Cervesato, Aaron D. Jaggard, and Andre Scedrov Supported by ONR URI

2. Kerberos Project Goals • Give precise statement and formal analysis of a real world protocol • Formalize and analyze Kerberos 5 using MSR • Identify and formalize protocol goals • Give proofs of achieved protocol goals • Gain experience in reasoning with MSR • Note any anomalous behavior • Consider possible fixes, test these

3. Background • Kerberos 4 • Analyzed using inductive approach (Bella & Paulson) • Kerberos 5 • Simplified version analyzed with Murφ (Mitchell, Mitchell, & Stern) • MultiSet Rewriting (MSR) • (Cervesato, Durgin, Lincoln, Mitchell, & Scedrov)

4. Achievements • Formalizations of fragments of Kerberos 5 • Using MSR 2.0 + extensions • Three formalizations (look at two here) • Formal analysis of protocol • Proofs of protocol properties • Using rank and corank functions (our focus here) • Properties and proofs show parallels between abstract and detailed formalizations • Curious behavior seen • Interactions with Kerberos designers

5. IntroductionKerberos OverviewFormalizing Kerberos 5Analyzing Kerberos 5 Anomalies

6. Kerberos 5 • Authentication • Repeatedly authenticate a client to multiple servers • Client C wants ticket for end server S • Tickets are encrypted – unreadable by C • C first obtains long term (e.g., 1 day) ticket from a Kerberos Authentication Server K • Makes use of C’s long term key • C then obtains short term (e.g., 5 min.) ticket from a Ticket Granting Server T • Based on long term ticket from K • C sends this ticket to S

7. Please give me ticket for T Ticket from K, one for S? Ticket from T Ticket for C to give to T Ticket for C to give to S Confirmation (optional) Error message (unencrypted) Protocol Messages C K C K C T C T C S C S C K|T|S

8. Introduction Kerberos Overview Formalizing Kerberos 5Analyzing Kerberos 5 Anomalies

9. Two Formalizations • Use MSR 2.0 + some extensions • Abstract formalization • Contains core protocol • Enough detail to prove authentication and confidentiality • Exhibits some curious behavior (structural) • Detailed formalization • Refines abstract formalization by adding options, checksums • Exhibits additional curious behavior

10. MSR Facts and States • Fix a first order signature corresponding to the protocol • Term t ::= a | x | f(t1, …, tn) • Fact F ::= P(t1, …, tn) • Predicate describes network, intruder knowledge, internal states, or stored data • State • Multiset of facts

11. MSR Rules • Transition rule R • C1, … , Ci,F1, …, Fjx1 … xm. G1, … , Gk • Constraints C1, … , Ci satisfied and M a multiset containing F1, …, Fj • Obtain new multiset M’ from M by • Deleting F1, …, Fj • Adding G1, … , Gk with fresh symbols in place of the xi • Free variables in rule universally quantified • Trace • Sequence of multisets with Mi+1 obtained from Mi via some rule ρi

12. IntroductionKerberos OverviewFormalizing Kerberos 5Analyzing Kerberos 5 Anomalies

13. Proof Methods • Two classes of functions defined on MSR facts • k-Rank • Data origin authentication • Work done to encrypt a specific message with key k • E-Corank • Confidentiality • Work needed to extract information using keys from the set E • Inspired by work of Schneider • Our corank functions parallel his rank functions

14. The k-rank of t relative to m0

15. The E-corank of t relative to m0

16. (Co)Rank of Facts and States • Rank of a j-ary predicate P: ρk(P(t1, …, tj); m0) = max{ρk(t1; m0), …, ρk(tj; m0)} • Rank of a finite multiset M of facts ρk(M; m0) = maxF in M{ρk(F; m0)} • Corank of a j-ary predicate P: cρk(P(t1, …, tj); m0) = min{cρk(ti1; m0), …, cρk(tin; m0)}, where ti1, …, tin are the ‘public’ terms • Look at those terms may be placed on the network later • In particular, cρE(I(m0); m0) = 0 • Corank of a finite multiset M of facts cρk(M; m0) = minF in M{cρk(F; m0)}

17. Effect of Rules on (Co)Rank • For a transition rule R: C1, … , Ci,F1, …, Fjx1 … xm. G1, … , Gk • Compare possible values of ρk({F1, …, Fj}; m0) and ρk({G1, … , Gk}; m0) • Compare possible values of cρk({F1, …, Fj}; m0) and cρk({G1, … , Gk}; m0) • Determine whether or not R can increase/decrese rank/corank

18. Intruder’s Use of Keys • A reasonable formalization should satisfy: • If intruder rule R increases ρk(_; m0), then lhs(R) contains I(k) (i.e., intruder knows the key k) • If intruder rule R decreases cρE(_; m0), then lhs(R) contains I(k) for some k in E or rhs(R) contains m0. • Our formalization of the Dolev-Yao intruder satisfies these properties

19. General Approach • Analogs of Schneider’s Rank Theorem • If ρk(F; m0) = 0 for every fact in initial state and no intruder rule can increase ρk(_; m0), then a fact F with ρk(F; m0) > 0 implies that some honest principal created {m0}k • Show that the must have been a certain principal • If cρE(F; m0) > 0 for every fact in initial state, no intruder rule can decrease cρE(_; m0), and no honest principal creates a fact F with cρE(F; m0) = 0, then m0 is secret • cρE(I(m0); m0) = 0

20. Using Rank and Corank • Determine which (co)rank function(s) are applicable to the desired property • Inspect rules of principals • Determine which can possibly raise rank or lower corank • Look at intruder rules • Find conditions which ensure that the intruder cannot raise rank/lower corank • Usually secrecy of certain key(s)

21. Please give me ticket for T Ticket from K, one for S? Ticket from T Ticket for C to give to T Ticket for C to give to S Confirmation (optional) Error message (unencrypted) Protocol Messages (Again) C K C K C T C T C S C S C K|T|S

22. KOpts,C,T,n1,e {Tflags,kCT,C}kT,{C,MD,t}kCT,Topts,C,S,n2,e SOpts,{Sflags,kCS,C}kS,{C,MD’,t’}kCS C,{Tflags,kCT,C}kT, {kCT,n1,Tflags,T}e’kC C,{Sflags,kCS,C}kS,{kCS,n2, Sflags,S}e’kCT [{t’}ekCS] KRB_ERROR,[-|t|t’],terr,ErrCode,C,(K|T|S) Two Formalizations C K C K C T C T C S C S C K|T|S

23. Properties Proved Abstract Abstract Detailed Detailed Abstract Abstract

24. Abstract Authentication Theorem • If T processes the message {kCT,C}kT, {C}kCT,C,S,n2 then some K created kCT and sent C,{kCT,C}kT, {kCT,n1,T}kC and C sent someX,{C}kCT,C,S’,n’2 • In Kerberos 4, Cmust have sent the ticket and not the generic X (Bella & Paulson) • Similar theorem for Client/Server exchange • Ticket came from T, authenticator from C

25. Detailed Authentication Theorem • Add details to obtain theorem for detailed formalization • Prove this by adding details to abstract level proof • If T processes the message {TFlags,kCT,C}kT, {C,ck,t}kCT,TOpts,C,S,n2,e then some K created kCT and sent C,{TFlags,kCT,C}kT, {kCT,n1,TFlags,T}kC and C sent someX,{C,ck,t}kCT,TOpts’,C,S’,n’2,e’ with ck = [TOpts’,C,S’,n’2,e’]kCT

26. Proving Authentication • Authenticate data origin using rank • Show ticket {TFlags,kCT,C}kT originates with some K • Show authenticator {C,ck,t}kCT originates with C • Relies on the confidentiality of kCT • Prove confidentiality of kCT using {kC,kT}-corank • No proper subset of {kC,kT} protects kCT • Abstract level proofs follow same outline

27. IntroductionKerberos OverviewFormalizing Kerberos 5 Analyzing Kerberos 5 Anomalies

28. Interesting curiosities, but don’t appear dangerous We’ve 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) Ticket option anomaly Effects similar to ticket switch anomaly Anomalies

29. Please give me ticket for Tusing etype (sent unencrypted) Ticket for C to give to T (other info encrypted using etype) Encryption Type Anomaly • Kerberos 5 allows C to specify encryption types that she wants used in K’s response • C’s key associated with the etype ebad is kbad • Intruder I learns kbad • C knows this and attempts to avoid ebad/kbad • I can still force kbad to be used C K C K

30. Kerberos 4: Ticket is enclosed in another encryption Kerberos 5: Ticket is separate from other encryption Ticket for C to give to T {Ticket, Other data}kC Ticket, {Other data}kC Ticket Anomaly C K

31. Please give me a ticket for T Ticket from K, ticket for S? X, Ticket for S? X, {Other data}kC Ticket for T, {Other data}kC Ticket for S. Ticket Anomaly C K I K C I (cuts Ticket) C I I T C T

32. Ticket Anomaly • T grants the client 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 • C’s view of the world is inaccurate • Some properties of Kerberos 4 don’t hold here • Seen in both formalizations • Variations possible using added detail • Anonymous tickets

33. C obtains tickets ST and ST’ with different options for use with server S C does not request mutual authentication from S, so she does not expect a response if the requests are successfully processed Assume that S can detect replays Saves authenticators in a cache (following RFC 1510) Ticket Option Anomaly

34. Ticket ST from T, {t}kCS Ticket ST’ from T, {t’}k’CS Ticket ST from T, {t}kCS Ticket ST from T, {t}kCS Replay error from time t Error at time t Ticket Option Anomaly C I C I I S (Accepted) I S I S C I

35. C’s request at time t was accepted, but her request at time t’ was 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 S’s 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 Ticket Option Anomaly

36. Conclusions • Formalizations of Kerberos 5 at different levels of detail • Extended MSR to do this • MSR can handle real world protocols • Proofs of properties which hold here • Parallel theorems and proofs in two formalizations • Authentication and confidentiality throughout • Gained additional experience in reasoning with MSR • Curious behavior • Interactions with Kerberos designers

37. Future Work • Systematize definition and use of (co)rank functions • Need to determine ‘public terms’ for corank • Analysis • Investigate temporal checks • Properties in more detailed formalizations • Anomalies – what can we still prove? Fix? Accept? • Extend formalizations • Add structure and functionality • Continue interaction with Kerberos designers