ECE 454CS 594 Computer and Network Security Dr

  • Slides: 44
Download presentation
ECE 454/CS 594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical

ECE 454/CS 594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011 1

Kerberos V 4 Tickets and ticket-granting tickets • Configuration • Replicated KDCs • Realms

Kerberos V 4 Tickets and ticket-granting tickets • Configuration • Replicated KDCs • Realms and interrealm authentication • Encryption for integrity only/privacy and integrity • Message formats • 2

Many-to-Many Authentication ? Users Servers � How do users prove their identities when requesting

Many-to-Many Authentication ? Users Servers � How do users prove their identities when requesting services from servers on the network? � Naïve solution: every server knows every user’s password: - insecure: compromise of any server will compromise all users - inefficient: a user must contact every server to change password 3

Using Trusted Third Party User requests ticket for some service; proves his identity Knows

Using Trusted Third Party User requests ticket for some service; proves his identity Knows all users’ and servers’ passwords User receives ticket User Ticket is used to access desired network service Servers Trusted authentication service on the network: � knows all passwords, can grant access to any server � convenient, but also the single point of failure � requires high level of physical security 4

Kerberos � Network authentication protocol � Provides strong authentication for client/server applications, using secret-key

Kerberos � Network authentication protocol � Provides strong authentication for client/server applications, using secret-key cryptography � A user types in a password and logs into a workstation. On behalf of the user, the workstation authenticates and accesses resources seamlessly � Developed at MIT � Kerberos V 4 and V 5 are widely deployed � KDC: a database of <principal, key> and a library of subroutines 5

Configuration • Kerberos server: KDC • Each principal has its master key, KAlice, shared

Configuration • Kerberos server: KDC • Each principal has its master key, KAlice, shared with KDC - human user: key is derived from password - machine: key is pre-configured • KDC has a master key, KKDC, known only by itself, to encrypt user master keys and ticket-granting tickets • KDC keeps a database of <principal, key>, where “key” for each user is encrypted by KKDC • Based on secret-key cryptography: DES, V 5 theoretically can use other encryption algorithms 6

Session Keys • For login sessions • Should we use the master key KAlice

Session Keys • For login sessions • Should we use the master key KAlice (long-term key)? • Use KAlice at the beginning of each session to negotiate a session key SA - eavesdropping - database reading - password guessing: online, offline (dictionary attack) 7

Ticket-Granting Ticket (TGT) • Recall: ticket TGT: KKDC{Alice, SA, expiration time, …}, for assigning

Ticket-Granting Ticket (TGT) • Recall: ticket TGT: KKDC{Alice, SA, expiration time, …}, for assigning the session key • Obtaining a TGT 8

Obtaining Services from A Remote Node After obtaining TGT, the credential for Alice… •

Obtaining Services from A Remote Node After obtaining TGT, the credential for Alice… • Step 1: Alice uses TGT to obtain a ticket • Step 2: Alice uses ticket to log into remote node • 9

Step 1: Obtaining A Ticket to Bob 10

Step 1: Obtaining A Ticket to Bob 10

Step 2: Accessing Bob 11

Step 2: Accessing Bob 11

Overview of Kerberos 12

Overview of Kerberos 12

Replicated KDCs • Purposes: - Prevent single point failure - Prevent performance bottleneck •

Replicated KDCs • Purposes: - Prevent single point failure - Prevent performance bottleneck • Multiple KDCs - One master copy for read/write - Multiple replicas for read only - All having the same database and the same master key • Updating KDC database - KDC’s database is transferred in clear - Privacy: keys are stored as ciphertext encrypted by KKDC - Integrity: a cryptographic hash of the database file and a timestamp 13

Realms To scale to a large network including multiple administrations, the principals are divided

Realms To scale to a large network including multiple administrations, the principals are divided into realms. Each realm has its own KDC. • The KDCs of other realms are treated as resources (principals) of a local realm. • 14

Interrealm Authentication • Kerberos V 4 does not allow authentication through a chain of

Interrealm Authentication • Kerberos V 4 does not allow authentication through a chain of KDCs: a rogue KDC can impersonate other realms • Kerberos V 5 does: hierarchy of realms 15

Interrealm Authentication (2) 16

Interrealm Authentication (2) 16

Key Version Numbers If Bob changes his master key, Alice’s ticket for Bob will

Key Version Numbers If Bob changes his master key, Alice’s ticket for Bob will be invalidated without Alice knowing it • Solution: Each key has a version number. Old keys are maintained for a period of time. Different keys are identified by their version numbers. Tickets are sent together with the key version numbers. • 17

Other Uses of Kerberos Besides authentication… • Integrity only: perform an undocumented arithmetic based

Other Uses of Kerberos Besides authentication… • Integrity only: perform an undocumented arithmetic based on mod 2^63 – 1 on the message concatenated with the session key, which results in a checksum. Send the message with the checksum • Privacy and integrity • 18

Privacy and Integrity • Plaintext Cipher Block Chaining (PCBC) - Modify any cipher block

Privacy and Integrity • Plaintext Cipher Block Chaining (PCBC) - Modify any cipher block will garble the rest of the message - Put recognizable data at the end of a message - Does not prevent swapping attack (why? ) 19

Message Types • • • AS_REQ TGS_REQ AS_REP (also TGS_REP) AP_REQ AP REP AS_REQ_MUTUAL

Message Types • • • AS_REQ TGS_REQ AS_REP (also TGS_REP) AP_REQ AP REP AS_REQ_MUTUAL AS_ERR AP_ERR PRIV SAFE 20

Use of AS_REQ Obtaining a TGT 21

Use of AS_REQ Obtaining a TGT 21

AS_REQ 22

AS_REQ 22

Use of TGS_REQ Obtaining a ticket to remote server Bob 23

Use of TGS_REQ Obtaining a ticket to remote server Bob 23

TGS_REQ 24

TGS_REQ 24

AS_REP and TGS_REP 25

AS_REP and TGS_REP 25

AS_REP and TGS_REP 26

AS_REP and TGS_REP 26

AS_ERR 27

AS_ERR 27

Tickets 28

Tickets 28

Authenticators 29

Authenticators 29

Credentials 30

Credentials 30

Use of AP_REQ and AP_REP Accessing the remote server Bob 31

Use of AP_REQ and AP_REP Accessing the remote server Bob 31

AP_REQ 32

AP_REQ 32

AP_REP and Encrypted Data PRIV • AP_REP is application specific, when mutual authentication is

AP_REP and Encrypted Data PRIV • AP_REP is application specific, when mutual authentication is needed, it takes the format of encrypted data PRIV Decrypted Data 33

SAFE: Integrity-Checked Data 34

SAFE: Integrity-Checked Data 34

AP_ERR 35

AP_ERR 35

Kerberos V 4 vs. V 5 Encryption system: V 4 requires DES, V 5

Kerberos V 4 vs. V 5 Encryption system: V 4 requires DES, V 5 can use any • Internet protocol: V 4 requires IP, V 5 can use other types • Message byte ordering: V 4 uses B BIT, all message structures are defined using Abstract Syntax Notation One (ASN. 1) and Basic Encoding Rules (BER) in V 5 providing unambiguous byte ordering • Ticket lifetime: 21 hours in V 4 (encoded in a 1 -octet quantity), V 5 tickets include explicit start and end time allowing arbitrary lifetimes • 36

Kerberos V 4 vs. V 5 (Cont’d) • • • Authentication forwarding/delegation: V 4

Kerberos V 4 vs. V 5 (Cont’d) • • • Authentication forwarding/delegation: V 4 does not allow and V 5 allows Interrealm authentication: no chaining in V 4 (N realms require O(N 2) Kerberos-to-Kerberos relationships), V 5 supports KDC hierarchy Session keys: negotiation of subsession keys is supported in V 5 for different sessions of the same service type Privacy + integrity: V 4 uses PCBC, V 5 uses explicit integrity mechanisms (e. g. , hash) with CBC encryption Password attacks: both versions are vulnerable 37

Exercises (1) [Kaufman] 13. 5: With CBC, if one ciphertext block is lost, how

Exercises (1) [Kaufman] 13. 5: With CBC, if one ciphertext block is lost, how many plaintext blocks are lost? With PCBC, why do things get back in sync if cn and cn+1 are switched? How about if a ciphertext block is lost? How about if ciphertext block n is switched with ciphertext block n+2? How about any permutation of the first n blocks? 38

Exercises (1): Answer [Kaufman] 13. 5: In CBC decryption, each ciphertext block affects two

Exercises (1): Answer [Kaufman] 13. 5: In CBC decryption, each ciphertext block affects two plaintext blocks, one through decryption and one through XOR. In PCBC decryption, each ciphertext block affects the corresponding plaintext block by XORing its decryption, while it affects all following plaintext blocks by XORing the XOR of it and its decryption. Thus, a set of ciphertext blocks affects the following plaintext blocks in a manner independent of the order of ciphertext blocks within the set—the effect is just an XOR of the XOR of all the ciphertext blocks and their decryptions. 39

Exercises (2) [Kaufman] 14. 4: Design a different method of Bob authenticating Alice when

Exercises (2) [Kaufman] 14. 4: Design a different method of Bob authenticating Alice when Bob does not remember his own master key, which places the work on Bob instead of Alice. In other words, Alice will act as if Bob was an ordinary civilized thing that does not remember its own master key, and Bob interacts appropriately with the KDC so that Alice will be unaware that Bob didn't know his own master key. 40

Exercises (2): Answer [Kaufman] 14. 4: We assume that Bob has a valid TGT

Exercises (2): Answer [Kaufman] 14. 4: We assume that Bob has a valid TGT and still remembers the session key SB. With the cooperation of the KDC, Bob can still decrypt messages encrypted with his master key, and thus authenticate Alice as follows. Bob gets the KDC to decrypt a message encrypted with his master key by sending the encrypted message and his TGT (which contains Bob’s name and the session key encrypted with the KDC’s master key) to the KDC. The KDC (which knows Bob’s master key) decrypts the message and sends it back to Bob encrypted with the session key. Since Bob knows the session key, he can now decrypt 41

Exercises (3) Alice wants to send Bob a large data file containing confidential data.

Exercises (3) Alice wants to send Bob a large data file containing confidential data. She wants to make sure the file cannot be modified undetected during transmission. All Alice and Bob have is their public/private key pair PUBA/PRVA and PUBB/PRVB, respectively. Show Alice will construct the message to be transmitted in a secure and efficient way. Show also how Bob will extract the data file from the received message. You can draw diagrams or write down the message construction/extraction using notations. 42

Exercises (3): Answer 43

Exercises (3): Answer 43

Reading Assignment • [Kaufman] Chapter 13 44

Reading Assignment • [Kaufman] Chapter 13 44