authenticator

Download Report

Transcript authenticator

VKSF 423 System Administration
III
Authentication Kerberos
Announcements


Slight modification to the syllabus
Office hours



Tuesday 10-12
Thursday 10-12, 2-3
Lab Three: Virtualized Storage




Veritas Storage Central
OpenAFS
LVM or EVMS
Dynamic Disks (MS DFS)
Syllabus Modifications
Old
Weight New
Component
Component
Due date
Labs
25%
No change
All sign offs and submission by the
end of 10th week
Practical
25%
No change
Demonstrated before exam week
begins
Group
Presentation
10%
In lab
In lab approximately 5 minutes
Group
Report
10%
Site Book
Due by end of 10th week
Homework
10%
Group
Evaluation
How did the individuals contribute
to the completion of the labs
Final Exam
20%
No change
During the final exam period
Definitions
Identification- assertion of who you are
 Authentication-process of proving one’s
identity
 Authorization-The privileges that accrue
to an identity
 Access control-Provide the correct
services to the correct users

Two Types of Authentication
User authentication
 Machine to machine authentication



Cryptographic
Other (weak)
Identification
Who are you?
 Who do you claim to be?
 Who are you acting as?

Authentication
Can you prove who you say you are?
 How?


Something you know


Something you are


Passwords
Biometrics
Something you have

Access tokens
Access Control
All of the above
 Allow the correct users




Into a system
Access to appropriate resources
Disallow invalid users


Entry to the systems
Deny access to restricted resources
Something you Know
Passwords

Oxymoron:
Large random string != easy to
remember

Password design/assignment



Storage


Multiple words/syllables
Mixed case/digits/punctuation
Weak/strong encryption
Users perceive the risks as minimal vs. need
to get work done
Passwords

Myth: never write down a password



Recovery
Helps more complicated passwords
Multiple passwords
Clues/questions
 One time passwords

Something you are
Biometrics



Voice, retinal, DNA, body geometry,
signature, finger prints
Hard to change
Easy to forge
Something you have
Access Tokens




Physical keys
Smart cards
Translators
Problems



Stolen
Duplicated
Spoofed
Authentication Protocols
Cryptographic methods to authenticate
over a network
 Multiple vulnerabilities

Network Authentication Options
Do nothing- trust machine to prevent
unauthorized user access (control physical
access)
Require machine to prove identity to network,
then trust machine to authenticate users and
provide access control
Require identification and authentication at
each resource
Authentication Requirements

Must be Secure


A.k.a. secure enough to push hackers
elsewhere
Must be reliable

Manageable level of false negatives and
false positives
Transparent to users
 Scalable to enterprise networks

Simple Protocol
Bob enters password on client
 Client sends password to server
 Server looks up id and password in
database of ids and passwords
 If it matches, validation message sent
to client & Bob is in

Problems with simple scenario
Clear text password in database
 Clear text password in transfer
 Confirmation spoofing

Password Database
Hide
 Encrypt



Salt
Multiple serial encryptions
Transfer
Hashing
 Encryption

Confirmation spoofing
Simple T/F
 Alternate hash of password/known key
 Encryption

Improved Protocol: Challenge
Avoid clear text transfer of password
 Bob informs server of desire to access
 Server offers a phrase to Bob
 Bob encrypts phrase with Bob’s
password and sends to server
 Server, who already knows Bob’s
password, also encrypts phrase with
Bob’s password and compares

Problems with improved
version
Server needs clear text copy of Bob’s
password
 Given enough instances of a login the
original password could be determined

Use of a “Trusted Third Party”

The “Blind Date” protocol






I don’t know Kathy
She doesn’t know me
We both know Loretta
We both separately contact Loretta
Loretta “vouches” for me to Kathy
Loretta “vouches” for Kathy to me
Levels of Kerberos Protection
Authentication at initiation of network
session, assume future messages from
same address come from same machine
 Authentication of each message, no
encryption of message
 Private messages-each message is
authenticated and encrypted

Kerberos Modules









Applications library
Encryption library
Database library
Database administration programs
Administration server
Authentication server
Db propagation software
User programs
applications
Kerberos Misc.


Model based on Needham and Schroeder key
distribution protocol
Encryption done with DES


Database



Extendable to DES Cypher Block Chaining
Contains one record/principal
Record contains name, private key, expiration date
of principal
Name- name.instance@realm
Kerberos

Ticket


Used to securely pass the identity of the person to
whom the ticket was issued between the
authentication server and the end server.
Authenticator

Contains additional information which when
compared against the ticket proves that the client
presenting the ticket is the same one to which the
ticket was issued.
Kerberos

Keeps database of clients and private
keys


If client is user, key is encrypted password
Generates temporary private keys
(session keys)

Session keys are given to two clients to
encrypt messages between them.
Kerberos Ticket

Ticket is good for a single server and a single client








Contains name of the server
Name of the client
IP address of the client
Timestamp
Lifetime
Random session key
Encrypted using the private key of the server for
which the ticket will be used
May be used until lifetime expires
Kerberos Authenticator

Contains






Name of the client
Client’s IP address
Client’s current time
Can only be used once, must be regenerated
each time a client wants to use a service
Can be regenerated by the client (without
going to the server)
Encrypted in the session key that is part of
the ticket
Enhanced protocol: Kerberos






Bob asks K-server to access Mary’s server
K-server checks to see if Bob has access
permissions
K-server sends Bob a ticket and a session
key
Bob uses session key to create an
authenticator to prove to Mary he is Bob
Bob send ticket and authenticator to Mary
Mary checks both
Main Problem
Authentication of user or device given
zero prior information
 Does Kerberos do this?
