coen 350 n.
Skip this Video
Download Presentation
COEN 350

Loading in 2 Seconds...

play fullscreen
1 / 50

COEN 350 - PowerPoint PPT Presentation

  • Uploaded on

COEN 350 . Kerberos. Kerberos. Provide authentication for a user that works on a workstation. Uses secret key technology Because public key technology still had patent projection. Implements authentication by Needham & Schroeder. On the market in versions 4 and 5. Kerberos.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'COEN 350' - eliana-mckee

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
coen 350

COEN 350


  • Provide authentication for a user that works on a workstation.
  • Uses secret key technology
    • Because public key technology still had patent projection.
  • Implements authentication by Needham & Schroeder.
  • On the market in versions 4 and 5.
  • Kerberos consists of
    • Key Distribution Center (KDC)
      • Runs on a physically secure node
    • Library of Subroutines
      • Modifies known UNIX libraries such as telnet, rlogin, …
key distribution center
Key Distribution Center
  • KDC:
    • Database of keys for all users
    • Invents and hands out keys for each transaction between clients.

Alice KDC Bob

Alice wants Bob

KAlice{ KAB for Bob }

KBob{KAB for Alice}

key distribution center1
Key Distribution Center
  • Message from KDC to Bob has some problems.
    • Timing problem: Alice needs to wait to make sure that Bob got the key.
    • Change the protocol so that Alice receives a ticket to talk to Bob.
key distribution center2
Key Distribution Center

Alice KDC Bob

KAlice{Use KAB for Bob}

Ticket for Bob :=

KBob{Use KAB for Alice}

Alice wants Bob

I’m Alice, my ticket is KBob{Use KAB for Alice}

key distribution center3
Key Distribution Center
  • Needham Schroeder:
    • Combines KDC operation with authentication.
    • Uses nonces instead of timestamps to prevent replay attacks.
      • A (sequential / random) number used only once.
needham schroeder
Needham Schroeder

N1, Alice, Bob




KAlice{N1, Bob, KAB, ticket to Bob}

Ticket, KAB{N2}

KAB{N2-1, N3}


Ticket = KBob{KAB, Alice}

needham schroeder1
Needham Schroeder

N1, Alice, Bob



Trudy (KDC)


Trudy as Bob

KAlice{N1, Bob, KAB, ticket to Bob}

Ticket = KBob{KAB, Alice}, …

But the nonces make all messages unique!

Trudy can now successfully authenticate herself to Alice as Bob.

Trudy impersonates the KDC and replays the old captured message, which looks like a normal message.

Trudy waits until Alice makes a request to the KDC.

Trudy now incorporates Bob.

Purpose of the nonce is the following scenario:

Assume that Trudy has stolen an old key of Bob’s and stolen the message where Alice previously has requested a key. Bob has in the meantime changed his key.

needham schroeder2
Needham Schroeder
  • Message 2: KAlice{N1, Bob, KAB, ticket} with ticket = KBob{KAB,Alice}
    • N1 prevents replay attacks.
    • “Bob” to prevent Trudy from trying to play Bob.
    • Ticket does not have to be sent encrypted with Alice’s key.
needham schroeder3
Needham Schroeder
  • Message 3: ticket, KAB{N2}
    • Alice presents a challenge together with her ticket.
    • Bob decodes ticket to find KAB.
    • He decodes the latter part of the message to find the challenge.
needham schroeder4
Needham Schroeder
  • Message 4: KAB{N2-1,N3}
    • Bob solves Alice’s challenge.
    • Bob sends Alice his own challenge.
      • Your turn: What is the vulnerability if message 4 were to read: KAB{N2-1}, KAB{N3} ?

Answer on next two slides.

needham schroeder5
Needham Schroeder
  • Answer:
    • Trudy eavesdrops on an exchange and then splices her own messages to Bob:
needham schroeder6
Needham Schroeder



Ticket, KAB{N2}

KAB{N2-1}, KAB{N3}

Replays Ticket, KAB{N2}

KAB{N2-1} KAB{N4}

Trudy (later)

Trudy now resumes her first connection: KAB{N4-1} and is authenticated

Ticket, KAB{N4}

KAB{N4-1} KAB{N5}

Trudy (second connection)

needham schroeder7
Needham Schroeder
  • Expanded Needham Schroeder
    • Prevents replay attacks after Alice’s key was stolen and changed.
needham schroeder8
Needham Schroeder
  • Vulnerability Scenario
    • Alice has a previous key JAlice that Trudy captured.
    • Alice has changed her key to KAlice.
    • Trudy has captured a previous login request from Alice to KDC:
      • KDC sent JAlice{N1,Bob,JAB,KBob{JAB,Alice}}
needham schroeder9
Needham Schroeder
  • Vulnerability Scenario
    • Trudy has JAlice{N1,Bob,JAB,KBob{JAB,Alice}}
    • Trudy calculates JAB and KBob{JAB,Alice} with JAlice.
    • Trudy now impersonates Alice to Bob. She sends her round 3 message to Bob:

N2, KBob{JAB,Alice}

    • She can complete the Needham Schroeder protocol with Bob.
    • Since the KDC no longer participates, informing the KDC of the change does not prevent Trudy from succeeding impersonating Alice to Bob.
needham schroeder10
Needham Schroeder
  • Solution:
    • Prevent replays after long duration:
      • Clock and date.
      • Certificate from Bob.
    • Extended Needham Schroeder picks the latter.
extended needham schroeder
Extended Needham Schroeder

Alice to Bob: I want to talk to you.

Bob to Alice: KBob{NB}

Alice to KDC: N1, “Alice wants Bob”, KBob{NB}

KDC to Alice: KAlice{N1,“Bob”,KAB, KBob{KAB, “Alice”, NB}}

Alice to Bob: KBob{KAB, “Alice”, NB}, KAB{N2}

Bob to Alice: KAB{N2-1,N3}

Alice to Bob: KAB{N3-1}.

NB prevents the previous attack. Bob can determine whether Alice is using the key that the KDC has.

otway rees
Otway Rees
  • Replaces extended Needham Schroeder
  • Uses only 5 messages
  • Speed-up results from the “suspicious party” (Bob) going to the KDC.
otway rees1
Otway Rees

Alice to Bob: NC, Alice Bob KAlice{NA,NC,“A.”,“B.”}

Bob to KDC: KAlice{NA,NC, Alice, Bob, KBob{NB,NC,“A.”,“B.”}

KDC to Bob NC, KAlice{NA,KAB}, KBob{NB,KAB}

Bob to Alice: KAlice{NA,KAB}

Alice to Bob: KAB{NC}

  • Based on Needham Schroeder, but uses time instead of nonces.
  • Approximate time is easy in distributed systems.
  • Kerberos Authentication Service:

Alice to KDC N1 “Alice wants Bob”

KDC to Alice KAlice{N1, “Bob”, KAB, KBob{KAB, Alice, expir. Time}}

Alice to Bob KBob{KAB, “Alice”, expir. Time}, KAB{cur. Time}

Bob to Alice KAB{cur. Time +1}

  • Kerberos Setup
    • Master key shared by KDC with each principal.
    • When Alice logs into her machine, her station asks the KDC for a session key for Alice. The KDC also gives her a Ticket Granting Ticket. (TGT)
    • Alice’s workstation retains only the session key and the TGT.
    • Alice’s workstation uses the TGT to receive other tickets from the Ticket Granting Service (TGS).
  • Two entities:
    • Key distribution center.
      • Authentication Server (AS)
    • Ticket granting server (TGS).
    • Both need the same database, so they are usually on the same machine.
  • Logging in:









TGT = KKDC{Alice, SA}

Workstation calculates session key SAlice and TGT, throws KAlice away.

  • Why wait for the password?
    • Workstation should know Alice’s password for minimum time.
    • Kerberos v. 5 changes this.
      • The workstation would contain data on which a password cracker could be run.
  • Purpose of TGT
    • AS, TGS does not need to retain session state.
    • Can recuperate quickly from a crash.
  • Remote Login
    • Step 1: Get a ticket for Bob.
    • Step 2: Use the ticket to log into Bob.




TGS_REQ{ Alice to Bob, TGT, SA{timestamp}}

rlogin Bob

Gets SA from TGT, verifies timestamp, creates ticket to Bob

KBob{ Alice, KAB }

TGS_REP{ SA{“Bob”, KAB, KBob{Alice, KAB}}




AP_REQ{ KBob{Alice, KAB}, KAB{timestamp}}

Bob decrypts the ticket to find KAB.

He then checks the timestamp.

AP_REP{ KAB {timestamp + 1}}

Workstation authenticates Bob because Bob has proven he knows KAB.

  • After the successful rlogin, Alice and Bob are not forced to use KAB
  • But they can.
  • Replicated KDC
    • To remedy single point of failure.
    • To remedy bottleneck.
    • Critical design point is the master key database.
    • Can be made read-only at replicated KDC and updated by a single master.
    • Updates of the master key database need to be protected against substitution attacks.
  • Realms
    • Every entity in a Kerberos realm trusts the Kerberos TGS & AS.
    • Each realm has its own master key database.
    • Principals in one realm can be authenticated to principals in another realm.

Realm 1


Request and ticket for KDC in Realm 2

Realm 2

Request and ticket for KDC in Realm 3

Realm 3


  • A single rogue KDC cannot subvert this process and grant tickets for things in other realms.
  • Tickets contain
    • Newly minted authentication key KAB
    • Name of requestor
    • Expiration Time
      • At most 23 hours
  • Keys contain version numbers.
    • This allows a key change without invalidating all pending requests.
    • Important for batch jobs when additional authentication is not possible.
  • Kerberos messages contain network addresses in the TGT.
  • The TGS checks for the network address when granting tickets.
    • This is not much of a protection
      • It is easy to fake network addresses
      • But together with a firewall might be useful to thwart attackers from outside.
  • Kerberos puts 4B IPv4 address inside a ticket.
  • Recipient of ticket checks whether the source IP address is the same as in the ticket.
  • Prevents use of a stolen session key and TGT.
    • Probably not worth the trouble, since it is easy to spoof IP addresses.
    • Generates problems with NAT.
    • Makes delegation of rights difficult / impossible.
  • Version 5 updates
    • ASN.1 data representation language
      • No fixed message formats.
      • Adds considerable overhead.

ASN.1 is presented in COEN 351.

  • Optional delegation.
    • Delegation of rights allows someone to give them their access rights for a limited scope and limited time.
      • Important to allow access to resources by a long-lasting batch-job.
    • Cannot be done by handing out the master key, or there would be no limitation to the delegation.
    • Handing tickets to the batch-job will not work if they are used after they expire.
  • Optional delegation.
    • Kerberos v. 5 allows Alice to ask for a TGT with a network address different from her address.
    • This TGT is not usable by Alice, but can be used by some entity to act on Alice’s behalf.
  • Optional delegation.
    • Limited Delegation
      • Alice can give Bob tickets to the specific service that he will need acting on her behalf.
        • Instead of giving Bob a TGT.
      • Alice can give Bob a TGT with the AUTHORIZATION-DATA field specified.
        • This field is interpreted by the application, not Kerberos.
        • Application reads the field to determine what Bob can do.
        • OSF/DCE and Windows 2000 use this field extensively.
  • Optional Delegation
    • Flag in TGT indicates whether delegation is allowed:
      • Forwardable Flag
        • TGT can be exchanged for a TGT with a different network layer address.
          • Alice decides whether the new TGT still has the forwardable flag set. In this way, Bob can ask Carol to act for him on behalf of Alice, …
      • Proxiable Flag
        • TGT can be used to request tickets (but not TGTs) with a different network address.
  • Ticket Lifetimes
    • There is a need for longer lived tickets, but granting them in general poses security risks.
    • K v. 5 allows
      • Specifying a start time.
      • An end time.
      • Authorization time.
      • Renew till times.
  • Alice can:
    • Get a renewable ticket.
      • Ticket is valid for 100 years.
      • But Alice needs to renew it daily.
      • Renewing a ticket is done by
        • Giving the ticket to the KDC and have the KDC reissue it.
        • If there is something wrong, the KDC can be told to not renew the ticket.
        • KDC only needs to retain revocation data for the ticket lifetime.
      • Uses the renewable flag.
  • Alice can:
    • Get a postdated ticket.
      • Used to run a batch-job sometimes in the future.
      • Kerberos uses the Start-Time field to indicate the future moment when the ticket becomes valid.
      • Original post-dated ticket is marked invalid.
      • If Bob wants to use the ticket, Bob has to present it to the KDC, which clears the invalid field.
        • This allows revocation of postdated tickets.
  • Key Versions
    • KDC maintains versions of keys.
      • Stored as
        • key (encrypted version of Alice’s key)
        • p_kvno (Alice’s key version number)
        • k_kvno (Version of KDC key used to obtain key)
    • Needed for
      • Post-dated tickets
      • Renewable tickets
  • Making Master Keys Different
    • Master keys in different realms should be different, when generated with the same password.
    • Kerberos v.5 uses a password to key hash function that has the realm name as an additional parameter.
      • Keys are different in different realms in an unpredictable way.