Coen 350
Download
1 / 50

COEN 350 - PowerPoint PPT Presentation


  • 73 Views
  • 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.

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

PowerPoint Slideshow about ' COEN 350 ' - eliana-mckee


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

Kerberos


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.


Kerberos1
Kerberos

  • 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

Bob

Alice

KDC

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

Ticket, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

Ticket = KBob{KAB, Alice}


Needham schroeder1
Needham Schroeder

N1, Alice, Bob

Bob

Alice

Trudy (KDC)

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

Bob

Alice

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}


Kerberos2
Kerberos

  • Based on Needham Schroeder, but uses time instead of nonces.

  • Approximate time is easy in distributed systems.


Kerberos3
Kerberos

  • 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}


Kerberos4
Kerberos

  • 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).


Kerberos5
Kerberos

  • 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.


Kerberos6
Kerberos

  • Logging in:

AS

Alice

Workstation

AS_REQ{Alice}

Alice

AS_REP{KAlice{SAlice,TGT}}

Password?

KAlice

TGT = KKDC{Alice, SA}

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


Kerberos7
Kerberos

  • 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.


Kerberos8
Kerberos

  • Purpose of TGT

    • AS, TGS does not need to retain session state.

    • Can recuperate quickly from a crash.


Kerberos9
Kerberos

  • Remote Login

    • Step 1: Get a ticket for Bob.

    • Step 2: Use the ticket to log into Bob.


Kerberos10
Kerberos

Alice

Workstation

TGS

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}}


Kerberos11
Kerberos

Bob

Workstation

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.


Kerberos12
Kerberos

  • After the successful rlogin, Alice and Bob are not forced to use KAB

  • But they can.


Kerberos13
Kerberos

  • 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.


Kerberos14
Kerberos

  • 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.


Kerberos15
Kerberos

Realm 1

Alice

Request and ticket for KDC in Realm 2

Realm 2

Request and ticket for KDC in Realm 3

Realm 3

Request


Kerberos16
Kerberos

  • A single rogue KDC cannot subvert this process and grant tickets for things in other realms.


Kerberos17
Kerberos

  • Tickets contain

    • Newly minted authentication key KAB

    • Name of requestor

    • Expiration Time

      • At most 23 hours


Kerberos18
Kerberos

  • Keys contain version numbers.

    • This allows a key change without invalidating all pending requests.

    • Important for batch jobs when additional authentication is not possible.


Kerberos19
Kerberos

  • 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.


Kerberos20
Kerberos

  • 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.


Kerberos21
Kerberos

  • Version 5 updates

    • ASN.1 data representation language

      • No fixed message formats.

      • Adds considerable overhead.

        ASN.1 is presented in COEN 351.


Kerberos22
Kerberos

  • 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.


Kerberos23
Kerberos

  • 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.


Kerberos24
Kerberos

  • 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.


Kerberos25
Kerberos

  • 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.


Kerberos26
Kerberos

  • 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.


Kerberos27
Kerberos

  • 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.


Kerberos28
Kerberos

  • 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.


Kerberos29
Kerberos

  • 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


Kerberos30
Kerberos

  • 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.


ad