The Kerberos Authentication System Course Outline

Transcription

1 The Kerberos Authentication System Course Outline Technical Underpinnings - authentication based on key sharing - Needham-Schroeder protocol - Denning and Sacco protocol Kerbeors V - Login and client-server authentication - Credential establishment and cache - Key Version Numbers - The KDC Database - Interrealm Authentication - Data Encryption - Data Integrity - Kerberos V Message Formats Kerbeors V 5 - ASN. Data Representation Language - Delegation of Rights - Ticket Lifetimes - Key Version Numbers - Interrealm Hierarchy - Preauthentication - KDC Database - Double TGT Authentication - Data Encryption / Integrity - Kerberos V 5 Message Formats and Protocol Flows Kerberos Future Developments and Use

2 Kerberos V Technical Underpinnings and Description

3 Authentication ased on Secret-Key Sharing A K A A and share secret key K A One-way authentication (?) A A { I } K A I Two-way (mutual) authentication A A { I A, I } K A I { I A } K A

4 Pairwise Authentication - O(n 2 ) keys A F C E D Trusted Third-Party Authentication - O(n) keys A KDC F C E D KDC shared long-term key (e.g., 6 mos.) shared session key (e.g., 8 hours) Key Distribution Center

5 Needham - Schroeder s Protocol (978) A = initiator peer, client; = recipient peer, server; K A = A s private, long-term, key K = s private, long-term, key I a, I A = A s nonces (challenges) I = s nonce (challenge) KDC (AS) = Authentication Server A KDC AS K ab <A, K A > <, K >. A,, I a 2. { I a,, K ab, { A, K ab } K }K A 3. { A, K ab } K A 5. { I - } K ab. { I } K ab Steps - 3 : distribution of session key K ab Steps, 5 : one-way authentication; i.e., authenticates A. { I } K ab A 5. { I -, I A } K ab 6. { I A- } K ab Steps - 6 : two-way(mutual) authentication of A and

6 Needham - Schroeder s Protocol (ctnd.). What if I a is not used in messages, 2? Intruder X can replay an old AS response to A s request. A, 2. {, K old-ab, { A, K old-ab } K }K A - forces the reuse of an old session key past the key s lifetime 2. What if identity is not used (encrypted) in message 2? Registered user X can masquerade as, and can make A believe it is communicating with - changes to X in message. - intercepts messages 3, 5 and generates correct responses, 6.. A, X 2. {, K ax, { A, K ax } K X }K A 3. { A, K ax } K x What if A repeatedly requests a session with from AS? A obtains known plaintext-ciphertext pairs < K i ab, { A, Ki ab }K >, i=,..., n and performs cryptanalysis to discover s secret key K. Countermeasures: () replace { A, K i ab }K with { TK i } K { A, Ki ab }TK i where TK i is a temporary key unknown to A. (2) use { confounder i, A, K i ab }K instead of { A, Ki ab }K where confounder i is a (pseudo) random number.. What if intruder X discovers K ab ( but not K A or K )? Intruder X can masquerade as A, and can make believe it is communicating with A - replays message { A, K ab } K - knows f = I -, and generates correct response 5. This vulnerability was pointed out by Denning and Sacco in 98

7 Denning and Sacco s Protocol (98) Same assumptions as Needham s and Schroeder s. In addition, T = timestamp is generated by AS, and all clocks are tightly synchronized; i.e., CLOCK i -T < t + t 2, for all i = A,, and where t = discrepancy between local clocks and AS clock t 2 = network delay. A -> AS : A, 2. AS -> A : {, K ab, T, { A, K ab,t } K }K A 3. A -> : { A, K ab,t } K. -> A : { I } K ab 5. A - > : { I - } K ab Limited lifetime of { A, K ab,t } K has the following consequences: the ticket { A, K ab,t } K cannot be replayed (or reused) an intruder that discovers K ab cannot masquerade as A However, network delays or out-of-synch local clocks can cause denial of service and lifetime limit for K ab cannot be enforced by ticket { A, K ab,t } K (no lifetime limit) ticket { A, K ab,t } K cannot be cached and reused by A.

8 Kerberos V (MIT ) Login and Peer-to-Peer/ Client-Server Authentication A AS K a-tgs TGS <A, KA > <, K > <TGS, K TGS > TGS 2 3 A K ab KDC A 5 6. AS_REQ : A, T a, lifetime, TGS 2. AS_REP: A, T a, expr_time, { K a-tgs, TGS, expr_time, { Ticket a-tgs } K TGS, T a }K A where Ticket a-tgs = < K a-tgs, lifetime, T kdc, TGS > 3. TGS_REQ : { Ticket a-tgs } K TGS, { authenticator a-tgs }K a-tgs, T a2, lifetime 2, where authenticator a-tgs = < A, checksum, T a2 >. TGS_REP : A, T a2, expr_time 2, { K ab,, expr_time 2, { Ticket ab } K, T a2 }K a-tgs where Ticket ab = < K ab, lifetime 2, T kdc2, > 5. AP_REQ : { Ticket ab } K, { authenticator ab }K ab (for one-way authentication) where authenticator ab = < A, checksum 2, T a3 > 6. AP_REP : { checksum 2 + } K ab = OPTIONAL (for mutual authentication)

9 Credential Establishment and Cache Credential cache is held in a file accessible only by the user s processes. Cache entries are filled by the execution of messages - of Kerberos. Cache entry structure returned by get_cred. Client A s credential cache TGS credential (service) s name (service) s instance (service) s realm session key K ab service credential ticket lifetime key version number ticket ticket issue date (client) A s name (client) A s instance

10 Key Version Numbers (krb v ) Motivation: oth users and servers change their keys over time. (e.g., passwords, server keys). Outstanding tickets may exist which are encrypted with old key. Unless servers remember old keys, communication fails. Failed communication cannot always be reinitiated (e.g., batch applications fail). Approach: Maintain a version number for each key. Servers responsibility to save keys with older version numbers. Tickets and protocol messages only include the expected key version number. Maximum number of old keys do not typically exceed two to three. (max. life of a K V ticket is about 2 hours plus max. KDC update delay; exception: long-life patches allowing one-month tickets) Limitation: Password updates may not propagate to all slaves instantaneously. User logins transparently directed to a KDC slave may fail for a until password updates propagate to KDC slaves. Users must remember previous password (e.g., previous version).

11 Network-Layer Addresses in Tickets Motivation:Theft of credential cache entries (i.e., tickets and corresponding session keys) use of stolen tickets and session keys from foreign network locations Situation: unattended workstations, root privileges to someone else s system Note: Theft of tickets and authenticators alone by an intruder does not give the intruder a ticket s session key Nevertheless, theft of tickets and authenticators can be a threat for all applications that do not use the session key and detect attack beyond initial authentication. Approach: Place ticket user s network-layer (e.g., IP) address in ticket. (Why not in authenticator?) Limitations: Approach disallows legitimate delegation of credentials. Network-layer addresses can be faked without great difficulty.

12 KDC Replication Motivation: Avoid single point of failure and performance bottleneck Approach: Maintain a single Master KDC and multiple Slave KDCs. Master KDC is Readable / Writeable whereas Slave KDCs are Read-only. Slave KDCs are updated periodically by Master KDC, or by administrative command. Unencrypted file containing Master KDC database is downloaded to each Slave KDC Reason: Most KDC operations require Read-only access KDC updates are typically required for infrequent operations; e.g., add / delete users, change passwords. Threat: Unauthorized disclosure of users passwords. Unauthorized modification of user and account data - create / modify user accounts and their properties; - replace (encrypted) user s password entry with attacker s Protection: Maintain the integrity of the Master KDC file copy in transit. - compute a hash function of the Master KDC file copy. - send the hash function to each Slave KDC in a krb_safe message. Residual Threat: Ciphertext-only attack against the users password entries. Some user privacy concerns (e.g., user registration attributes).

13 Interrealm Authentication Key Sharing L.KDC K L-R R.KDC K A K A@L K Protocol Message Flows L.KDC R.KDC L.AS <A, K A > <, K > R.AS L.TGS < R.TGS, K L-R > < L.TGS, K L-R > R.TGS K A-R.TGS K ab A@L 8

14 Non-Transitive Authentication Trust (krb v) Key Sharing L.KDC K L-M M.KDC K M-R R.KDC K A K A@L K C@R Motivation: Penultimate, rogue KDC of a KDC chain (i.e., L.KDC) can impersonate both local and foreign users. Protection: User A.L s ticket for R.KDC ( i.e., K A-R.TGS ) includes realm name L, and is made by M.KDC ( i.e., encrypted with K M-R ). Realm R.KDC will refuse a ticket made by M.KDC for a foreign user (i.e., a user of L.KDC, or of any other realm but M.KDC). Limitation: Manage and protect O( n 2 ) shared cross-realm keys. Establish O( n 2 ) trust relations.

15 Encryption for Confidentiality and Integrity CC Encryption Mode Encryption and Decryption IV Requirements CC Invariant Property PCC Encryption Mode Encryption and Decryption PCC Invariant Property Data Encryption (for Confidentiality) Data Integrity

16 CC Encryption Mode Encryption : C n = { C n- P n } K, where C 0 = IV p p 2 p 3 p IV key EC-e EC-e EC-e EC-e c c 2 c 3 c Decryption : C n- {C n } K - = P n, where C 0 = IV c c 2 c 3 c key EC-d EC-d EC-d EC-d IV p p 2 p 3 p

17 CC Encryption Mode (ctnd) IV Requirements. IV Must be Secret ( and Random) Chosen Plaintext Attack: Let IV a, IV b be known, and K, P be secret. Choose X i such that { IV a X i } K = { IV b P } K Then, IV a IV b X i = P 2. IV Must be Selected / Changed per Association (e.g., per session) Chosen Plaintext Attack: Let IV be constant (but secret) and P be secret (but predictable). P has a few known values P, P2,..., Pn Steal { IV P } K and construct a table of 2 56 entries for each P i, each entry containing { IV Pi }Kj Find an entry s.t. { IV P } K = { IV P i }Kj and ( secret ) key K = Kj. 3. IV Must be Protected from Predictable Modification Modification Attack: Predictable change of IV[i] bit causes predictable change of P [i] bit, even if P is secret. C = { IV P } K => P [i] = IV [i] { C } K - [i] = IV [i] { C } [i] K -

18 CC Encryption Mode (ctnd) Encryption : C n = { C n- P n } K Decryption : K C n {C n+ } - = P n+ => modify P n+ [i] modify C n [i] C n- {C n } K - = P n => random P n CC Invariant Property IV p p 2 p i- p i p i+ p n c c 2 c i- c i c i+ c n Decompose Splice c c 2 c i- c i c i+ c n IV p IV s p p 2 p i- p i p i+ p n P = P IV p IV P i = C i- P i IV s

19 The Cipher Feedback (CF) mode of the DES Synchronized 6-bit shift register inputs (initial value from IV) Key DES (Encipher) DES (Encipher) Key CLEARTEXT CIPHERTEXT CLEARTEXT

20 PCC Encryption Mode Encryption : C n = {C n- P n- P n } K, where C 0 =IV, P 0 = 0 p p 2 p 3 p IV key EC-e EC-e EC-e EC-e c c 2 c 3 c Decryption : C P n- {C n } = P n, where C 0 =IV, P 0 = 0 K - n- c c 2 c 3 c key EC-d EC-d EC-d EC-d IV p p 2 p 3 p

21 PCC Encryption Mode (ctnd) Encryption : C n = {C n- P n- P n } K Decryption : {C n } K- C n- => random P n P n- = P n modify C n [i] K - C n P n {C n+ } = P n+ => random P n+ => random P n+m PCC Invariant Property IV p p 2 p i- p i p i+ p n c c 2 c i- c i c i+ c n Decompose Splice c c 2 c i- c i c i+ c n IV p IV s p p 2 p i- p i p i+ p n P = P IV p IV P i = C i- P i P i- IV s

22 Data Encryption (for Confidentiality) krb_priv Kv priv length(encr) kv priv length(encr) length data 5 ms t-stamp sender IP-addr d t-stamp pad key IV P PCC ENC C kv priv length(encr) length data 5 ms t-stamp sender IP-addr d t-stamp pad

23 Data Integrity krb_safe Kv safe length(data) data 5 ms t-stamp sender IP-addr d t-stamp pad K ab cksum Kv safe length(data) data 5 ms t-stamp sender IP-addr d t-stamp cksum

24 Kerberos V Replay Detection (sliding time window w/o server replay cache) A s clock (fast) A s clock (loosely synchronized) A s (client s) clock (slow) s (server s) clock reject C 3 (t) Ti (server) must maintain replay cache reply C S (t)+5 min T 0 T C 2 (t) Tj C S (t) T 2 T 3 C S (t)-5 min reject C (t) Tk

25 Out-of-Synch Clocks Server 2 s clock Client A s clock Server s clock Ti C (t)+5 min T 0 T C (t) T 2 T 3 reject C (t)-5 min reject C A (t j ) Tj Q 0 C 2 (t)+5 min Ti C A (t i ) Q Q 2 Q 3 C 2 (t) C 2 (t)-5 min

26 Kerberos V Message Formats

27 Ticket # bytes 8 A s (i.e., client s) name A s (i.e., client s) instance A s (i.e., client s) realm A s network-layer (e.g., IP) adddress session key for A <-> (i.e., K ab ) ticket lifetime (5 min. units) KDC timestamp (i.e., ticket issue time) s (i.e., server s) name s (i.e., server s) instance 7 pad of 0 s to make ticket length a multiple of 8 bytes

28 Authenticator # bytes 7 A s (i.e., client s) name A s (i.e., client s) instance A s (i.e., client s) realm checksum A s (i.e., client s) timestamp (5 millisec.) timestamp pad of 0 s to make ticket length a multiple of 8 bytes

29 Credential field of a AS_REP or TGS_REP # bytes 8 7 session key for A <-> (i.e., K s ab ) (i.e., server s) name s (i.e., server s) instance s (i.e., server s) realm A s network-layer (e.g., IP) adddress ticket lifetime s (i.e., server s) key version number ticket length ticket KDC timestamp (i.e., ticket issue time) pad of 0 s to make cred. length a multiple of 8 bytes

30 AS_REQ # bytes Kerberos version () message type () A s (i.e., client s) name A s (i.e., client s) instance A s (i.e., client s) realm A s (i.e., client s) timestamp requested ticket lifetime s (i.e., server s) name s (i.e., server s) instance

31 TGS_REQ # bytes variable variable Kerberos version () message type (3) KDC s key version number KDC s realm length of TGT length of authenticator TGT authenticator A s (i.e., client s) timestamp requested ticket lifetime s (i.e., server s) name s (i.e., server s) instance TGT

32 AS_REP and TGS_REP # bytes Kerberos version () message type (2) A s (i.e., client s) name A s (i.e., client s) instance A s (i.e., client s) realm A s (i.e., client s) timestamp number of tickets () variable 2 ticket expiration time A s (i.e., client s) key version number credential length credential

33 AP_REQ # bytes variable variable Kerberos version () message type (8) s (i.e., server s) key version number s (i.e., server s) realm length of ticket length of authenticator ticket authenticator # bytes AP_REP - optional Kerberos version () message type (6) length of encrypted material () A s authenticator s checksum + # bytes AP_ERR Kerberos version () message type (8) error code error text (additional information)

34 KDC Error Reply # bytes Kerberos version () message type (32) A s (i.e., client s) name A s (i.e., client s) instance A s (i.e., client s) realm A s (i.e., client s) timestamp error code error text (additional information)

35 KR_PRIV # bytes variable Kerberos version () message type (6) length of encrypted material (e.g., data) length of data data A s (i.e., client s) timestamp (5 millisec.) variable D A s (i.e., client s) network-layer (i.e., IP) address timestamp pad of 0 s to make length a multiple of 8 bytes

36 KR_SAFE # bytes variable 6 Kerberos version () message type (7) length of data data A s (i.e., client s) timestamp (5 millisec.) A s (i.e., client s) network-layer (i.e., IP) address D timestamp (pseudo-jueneman) checksum

37 Laboratory Notes KDC Installation