Lecture 4 (Weds 10/8/97), part 2

Scribe: Martin Sweitzer

Kerberos Authentication

Flaws in Authentication Protocols

Kerberos
Neuman-Stubblebine
Taxonomy of Flaws

4 parts of Kerberos

Kerberos
Client
Tickeing Granting Service
Server

Steps:

0) Request for Ticket-Granting Ticket (sent as plaintext)
1) Kerberos sends back a Ticket-Granting Ticket
2) Request for Server Ticket from the TGS
3) Server Tciket is sent back to the client
4) Request for Service sent to the server

Message contents
0) c, tgs
1) {Kc, tgs}Kc, {Tc, tgsKtgs
2) {Ac,s}Kc, tgs, {Tc,tgs} Ktgs
3) {Kc,s} Kc,tgs, {Tc,s}Ks
4) {Ac,s}Kc,s, {Tc,s}Ks

A Kerberos Ticket

{Tc,s}Ks = {s, c, addr, timestamp, lifetim, Kc,s} Ks

Authenticator

{Ac}Kc,s = {c, addr, timestamp}Kc,s

Kerberos Has Weaknesses

Replay Attacks
Secure Time Services are needed
Password-Guessing Attacks
Spoofing Log-in
Kerberos Hardware Design Criteria

Replay Attacks

Authenticator relies on the timestamp to guard against reuse

The idea of the timestamp was that by the time the key is stolen the timestamp will have made it irrelevant. This is NOT true, everything the hackers need to use the key is already set up!

You can not do Live Authentication becuase of the limitations with current software (ie unix TCP forks a separate process to handle each incoming request.

Secure Time Services

Relies on clock Synchronization

Hosts can be misled about the time

Really hard problem to solve here. Can use a challenge and response mechanism, may have to expand the protocol... tho

Password Guessing

Kerberos relies on the client's password And one can guess the password as the initial request is encrypted with Kc
Can use Exponential Key Exchange (in Applied Cryptography) Encrypt first request (thos this adds 2 more messages to the protocol)

Spoofing Login

The Bad guys can just replace the login with a loging that records everyones password that uses that machine. (ie kerberos assumes that the login procedure is secure)

One time password might work here.

Session Key Exposure.

The key is used in multiple Sessions and is vulnerable to substituion.

Solution:
Have the session key be generated by the server. Computer as a session-specific function of the mult-session key

Ticket Scope

Tickets have a limited time.

Tickets are limited to realms

TGS is client to TGS in another realm
Realm reltionships become complicated
Realm routing protocols need strong authentication
Configuration Control of realms tables

There has been much talk about the pseudo random number generator. About if you know cen ata you are able to find the state of the pseudo random generator andthen able to find the session key. Once you have this you are IN!

Need better key generation

Kerberos Summary:

It assumes that ALL parts are secure. This is NOT true.

Neuman-Stubblebine

0) A generates Nonce Ra
1) Uses A1Ra with timestamp then sends with B timestamp
2) Creates 3 part message:
     gives nonce to A
     sends session key Kab to A
     sends nonce also
3) A can now send a message

Why is Neuman-Stubblebine good?

Does not rely on synchronized clocks
Smaller set of message than kerberos
Client and Server can re-authenticate without relying on auth. server it is bad form to double encrypt: gives more info opponent

Why is it bad?

Bad form to doubel encrypt. Gives the opponent more information.

Paradox Attack

X -> A, Rx -> B
B -> B, (A, Rx, Tb)Kbs, Rb -> S
S -> Ignore all -> X
X -> (A, Rx, Tb)Kbs, (Rb)Rx -> B

Parallel Session Attack

Rx, Stolen Ticket -->

<-- Rb, (Rx)Kab

Rb, Stolen Ticket ---->

<---- R'b (Rb)Kab

(Rb)Kab -->

Attacker uses the first run's bits to attack the second time.

Counter Measures:

Modiefied Initial Exchange Protocol

ciphertext of MSG 2 = ticket of MSG 3 (ie so you can look at the encrypted text and see if it the same)

Modiefied the Authen Protocol such that there is a Time stamp. That way the K is different

Over view of the Cryptographic Protocol Flaws

Elementary Flaws (you designed something badly)
Password Guessing Flaws
Freshless flaws
Oracle Flaws
Type Flaws
Internal Flaws
Cryptosystem-related flaws

Oracle Flaws

Three Pass Protocol

A to B {M}kA
B to A: {{M}Ka}Kb
A to B: {M}Kb

Single-role oracle attack

Alice to Eve-bob: {M}Ka
Eve-bob to Alice: {M}Ka
Alice to Eve-bob: M

Multi-role Environment

AliceA to Eve-bobB: {M}Ka
Eve-bobA to AliceB: {M}Ka
AliceB to Eve-bobA: M
Eve-bobB to AliceA: bogus
AliceA to Eve-bobB: {bogus}Ka

Eve gets Alice to generate a Bogus Message!!!

Type Flaws

Are a sub-class of Oracle Flaws

Type information can distinguish

- Cryptographic Protocol Identification
- Run Number
- Transmission Step
- Sub-component Identification
- Distinct words have primitive types

A Taxonomy of Replay Attacks

"Replay"- The capture of a message or a piece of a message that is then used at a later time

"Protocol Run" - any singl execution of a protocol by the relevant participants

Originnation Taxonomy
    - Run External Attacks
       - Interleavings
       - Classic Reaplys

   - Run Interna Attacks

Destination Taxonomy

Interleavings

Ban-Yahalom Protocol

0) A to B : A, Na
1) B to S: B, Nb, {A, Na}Kbs
2) S to A: Nb, {B, Kab, Na}Kas, {A, Kab, Nb}Kbs

{B, Kab, Na} = ticket

3) A to B: {A, Kab, Nb}Kbs, {Nb}Kab

0) A to B: A, Na
1) B to S: B, Nb, {A, Na}Kbs
(0') Ea to B: A,{Na, Nb)
(1') B to Es: B, N'b, {A, Na, Nb}Kbs
2) Omitted
3) Ea to B: {A, Na(=Kab), Nb}Kbs, {Nb}Kab

Destination Taxonomy Summary

Deflections - Message is directed to other than the intened recipient
-Reflections-Message is sent back to sender
-Deflections-Message is sent to a third party

Straight replays - Intended principal receives message, but message is delayed

Countermeasures

Taxonomies provide insight to countermeasures

Proposed Countermeasures
  - message typing
  - sender and reciever identification
  - asymmetrical message types

Useful for determining appropriate analysis techniques