Scsc 455 computer security
This presentation is the property of its rightful owner.
Sponsored Links
1 / 24

SCSC 455 Computer Security PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on
  • Presentation posted in: General

SCSC 455 Computer Security. Chapter 4 Key Distribution and User Authentication (part I) Dr. Frank Li. Index. Symmetric Key Distribution Using Symmetric Encryption Kerberos Key Distribution Using Asymmetric Encryption X.509 Certificates PKI Federated Identity Management.

Download Presentation

SCSC 455 Computer Security

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


Scsc 455 computer security

SCSC 455 Computer Security

Chapter 4 Key Distribution and User Authentication (part I)

Dr. Frank Li


Index

Index

  • Symmetric Key Distribution Using Symmetric Encryption

  • Kerberos

  • Key Distribution Using Asymmetric Encryption

  • X.509 Certificates

  • PKI

  • Federated Identity Management


Symmetric key distribution using symmetric encryption

Symmetric Key Distribution Using Symmetric Encryption

  • In symmetric encryption, key must be protected from access by others

    • Also frequent key changes are desirable, because …

    • The strength of cryptosystem rests on Key distribution technique

  • Four options of key distribution

    • A key is selected by A and physically delivered to B

    • A key is selected by a third party C and physically delivered to A and B

    • Using the old key to encrypt the new key before transmission

    • a third party C deliver a key on encrypted link to A and B


Key distribution center kdc

Key Distribution Center (KDC)

  • Issues with option 1, 2 and 3

  • Two types of keys in option 4

    • Session key vs. Permanent key

    • KDC is necessary element

  • KDC operation

    • A transmit a connection request packet to KDC

    • KDC generates a one-time session key. KDC encrypt session key with a permanent key shared with A, and delivery the encrypted session key to A. same to B

    • A and B set up a logical connection with the session key


Kerberos

Kerberos

  • Kerberos is a key distribution and user authentication service

    • The problem Kerberos addresses is …

    • Kerberos provides a centralized authentication server to authenticate users to servers and servers to users.


Authentication requirements

Authentication Requirements

  • Security

    • Against attacks by passive eavesdroppers and actively malicious users

  • Reliability

  • Transparency

    • Users shouldn’t be aware of authentication taking place

    • Entering password is Ok, if done rarely

  • Scalability

    • Large number of users and servers


Authentication threats

Authentication Threats

  • User impersonation

    • Malicious user with access to a workstation pretends to be another user from the same workstation

      • Can’t trust workstations to verify users’ identities

  • Network address impersonation

    • Malicious user changes network address of his workstation to impersonate another workstation

  • Eavesdropping, tampering and replay

    • Malicious user eavesdrops on, tampers with or replays other users’ conversations to gain unauthorized access


History of kerberos

History of Kerberos

Kerberos is

  • Part of project Athena (MIT).

  • Trusted 3rd party authentication scheme

  • Assumes that hosts are not trustworthy.

  • Requires that each client (each request for service) prove it’s identity.

  • Does not require user to enter password every time a service is requested


Solution trusted third party

Servers

Solution: Trusted Third Party

  • 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

Knows all users’ and

servers’ passwords

User requests ticket for some

service; proves his identity

User receives ticket

Ticket is used to access

desired network service

User


Kerberos v4

Kerberos V4

  • A simple authentication dialogue

    Authentication Server (AS)

  • A more secure authentication dialogue

    • Ticket-granting server (TGS)

    • Ticket

      • Timestamp and lifetime

  • The version 4 authentication dialogue


What should a ticket look like

What Should a Ticket Look Like?

  • Ticket cannot include server’s plaintext password

    • Otherwise, next time user will access server directly without proving his identity to authentication service

  • Solution: encrypt some information with a key derived from the server’s password

    • Server can decrypt ticket and verify information

    • User does not learn server’s password

Ticket gives holder

access to a network service

User

Server


What should a ticket include

What Should a Ticket Include?

Knows all users’ and

servers’ passwords

  • User name

  • Server name

  • Address of user’s workstation

    • Otherwise, a user on another workstation can steal the ticket and use it to gain access to the server

  • Ticket lifetime

  • A few other things (e.g., session key)

User

Encrypted

ticket

Server

Encrypted

ticket


How is authentication done

How Is Authentication Done?

  • Send the password each time to obtain the ticket for any network service

    • Separate authentication for email, printing, etc.  Inconvenient

Password

User

Encrypted

ticket

Authentication server


Solution two step authentication

Solution: Two-Step Authentication

  • Prove identity once to obtain special TGS ticket

    Instead of password, use key derived from password

  • Use TGS to get tickets for many network services

USER=Joe; service=TGS

Joe the User

Encrypted TGS ticket

Key distribution

center (KDC)

TGS ticket

Ticket granting

service (TGS)

Encrypted

service ticket

File server, printer,

other network services

Encrypted

service ticket


Still not good enough

Still Not Good Enough

  • Ticket hijacking

    • Malicious user may steal the service ticket of another user on the same workstation and use it

      • IP address verification does not help

    • Servers must be able to verify that the user who is presenting the ticket is the same user to whom the ticket was issued

  • No server authentication

    • Attacker may misconfigure the network so that he receives messages addressed to a legitimate server

      • Capture private information from users and/or deny service

    • Servers must prove their identity to users


Symmetric keys in kerberos

Symmetric Keys in Kerberos

  • Kc is long-term key of client C

    • Derived from user’s password

    • Known to client and key distribution center (KDC)

  • KTGS is long-term key of TGS

    • Known to KDC and ticket granting service (TGS)

  • Kv is long-term key of network service V

    • Known to V and TGS; separate key for each service

  • Kc,TGS is short-term key between C and TGS

    • Created by KDC, known to C and TGS

  • Kc,v is short-term key betwen C and V

    • Created by TGS, known to C and V


Single logon authentication

“Single Logon” Authentication

kinit program (client)

  • Client only needs to obtain TGS ticket once (say, every morning)

    • Ticket is encrypted; client cannot forge it or tamper with it

Key Distribution

Center (KDC)

password

IDc , IDTGS , timec

Convert into

client master key

User

Kc

EncryptKc(Kc,TGS, IDTGS , timeKDC ,

lifetime , ticketTGS)

Decrypts with

Kc and obtains

Kc,TGS and

ticketTGS

Fresh key to be used

between client and TGS

TGS

Key = KTGS

EncryptKTGS(Kc,TGS , IDc , Addrc ,

IDTGS , timeKDC , lifetime)

Client will use this unforgeable ticket to

get other tickets without re-authenticating

Key = Kc

All users must

pre-register their

passwords with KDC


Obtaining a service ticket

Obtaining a Service Ticket

Ticket Granting

Service (TGS)

usually lives inside KDC

  • Client uses TGS ticket to obtain a service ticket and a short-term key for each network service

    • One encrypted, unforgeable ticket per service (printer, email, etc.)

Client

EncryptKc,TGS(IDc , Addrc , timec)

Proves that client knows key Kc,TGS

contained in encrypted TGS ticket

Knows Kc,TGS

and ticketTGS

System command,

e.g. “lpr –Pprint”

IDv , ticketTGS, authC

EncryptKc,TGS(Kc,v, IDv , timeTGS ,

ticketv)

User

Fresh key to be used

between client and service

Knows key Kv for

each service

EncryptKv(Kc,v, IDc, Addrc, IDv,

timeTGS, lifetime)

Client will use this unforgeable

ticket to get access to service V


Obtaining service

Obtaining Service

  • For each service request, client uses the short-term key for that service and the ticket he received from TGS

Client

EncryptKc,v(IDc , Addrc , timec)

Proves that client knows key Kc,v

contained in encrypted ticket

KnowsKc,v

and ticketv

Server V

System command,

e.g. “lpr –Pprint”

ticketv, authC

EncryptKc,v(timec+1)

User

Authenticates server to client

Reasoning:

Server can produce this message only if he knows key Kc,v.

Server can learn key Kc,v only if he can decrypt service ticket.

Server can decrypt service ticket only if he knows correct key Kv.

If server knows correct key Kv, then he is the right server.


Kerberos in large networks

Kerberos in Large Networks

  • One KDC isn’t enough for large networks

    • Network is divided into realms

    • KDCs in different realms have different key databases

  • To access a service in another realm, users …

    • Get ticket for home-realm TGS from home-realm KDC

    • Get ticket for remote-realm TGS from home-realm TGS

      • As if remote-realm TGS were just another network service

    • Get ticket for remote service from that realm’s TGS

    • Use remote-realm ticket to access service

    • N(N-1)/2 key exchanges for full N-realm interoperation


Important ideas in kerberos

Important Ideas in Kerberos

  • Use of short-term session keys

    • Minimize distribution and use of long-term secrets; use them only to derive short-term session keys

    • Separate short-term key for each user-server pair

      • But multiple user-server sessions reuse the same key!

  • Proofs of identity are based on authenticators

    • Client encrypts his identity, address and current time using a short-term session key

      • Also prevents replays (if clocks are globally synchronized)

    • Server learns this key separately (via encrypted ticket that client can’t decrypt) and verifies user’s identity


Practical uses of kerberos

Practical Uses of Kerberos

  • Email, FTP, network file systems and many other applications have been kerberized

    • Use of Kerberos is transparent for the end user

    • Transparency is important for usability!

  • Local authentication

    • login and su in OpenBSD

  • Authentication for network protocols

    • rlogin, rsh, telnet

  • Secure windowing systems

    • xdm, kx


Kerberos version 5

Kerberos Version 5

  • The environmental limitations of Kerberos version 4

    • Encryption system dependence

    • Internet protocol dependence

    • Message byte ordering

    • Ticket lifetime

    • Authentication forwarding

    • Inter-realm authentication


Summary of kerberos

Summary of Kerberos


  • Login