Transcript Lecture 9

ECE454/599
Computer and Network Security
Dr. Jinyuan (Stella) Sun
Dept. of Electrical Engineering and Computer Science
University of Tennessee
Fall 2012
1
Kerberos V4
•
•
•
•
•
•
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
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 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 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 V4 and V5 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 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, V5 theoretically
can use other encryption algorithms
6
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 the session key
Obtaining a TGT
8
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 2: Accessing Bob
11
Overview of Kerberos
12
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 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 V4 does not allow authentication through a chain
of KDCs: a rogue KDC can impersonate other realms
• Kerberos V5 does: hierarchy of realms
15
Interrealm Authentication (2)
16
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 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 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
• AS_ERR
• AP_ERR
•
•
PRIV
SAFE
20
Use of AS_REQ
Obtaining a TGT
21
Tickets
22
AS_REQ
23
AS_REP and TGS_REP
24
Credentials
25
Use of TGS_REQ
Obtaining a ticket to remote server Bob
26
TGS_REQ
27
AS_REP and TGS_REP
28
Authenticators
29
Use of AP_REQ and AP_REP
Accessing the remote server Bob
30
AP_REQ
31
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
32
SAFE: Integrity-Checked Data
33
AS_ERR
34
AP_ERR
35
Kerberos V4 vs.V5
• Encryption system:V4 requires DES,V5 can use any
• Internet protocol: V4 requires IP, V5 can use other types
• Message byte ordering: V4 uses B BIT, all message
structures are defined using Abstract Syntax Notation
One (ASN.1) and Basic Encoding Rules (BER) in V5
providing unambiguous byte ordering
• Ticket lifetime: 21 hours in V4 (encoded in a 1-octet
quantity),V5 tickets include explicit start and end time
allowing arbitrary lifetimes
• Master keys are different in different realms in V5
36
Kerberos V4 vs.V5 (Cont’d)
• Authentication forwarding/delegation: V4 does not allow
•
•
•
•
and V5 allows
Interrealm authentication: no chaining in V4 (N realms
require O(N2) Kerberos-to-Kerberos relationships),V5
supports KDC hierarchy
Session keys: negotiation of subsession keys is supported
in V5 for different sessions of the same service type
Privacy + integrity:V4 uses PCBC,V5 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 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
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
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 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 the message.
41
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 how 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
The message in the signature
(the last item) should be
hashed first for better
efficiency
43
Reading Assignment
• [Kaufman] Chapter 13
44