SMU CSE 5349/7349 1

Authentication Protocols

SMU CSE 5349/7349 2

The Premise

How do we use perfect cryptographic mechanisms (signatures, public-key and symmetric key encryption, hash functions, MACs) to design secure protocols (providing security services) over an un-trusted network?

SMU CSE 5349/7349 3

Types of Authentication

• Peer entity authentication– Prevent masquerading– Ensure freshness

• Data origin authentication– Claims of data origin– Prevention of forgeryWe are dealing with Entity

Authentication

SMU CSE 5349/7349 4

Definitions

• Entity authentication:– Corroboration that an entity is the one

claimed at a particular point in time.• Unilateral authentication:

– Provides one entity with assurance of the other’s identity but not vice versa.

• Mutual authentication:– Provides both entities with assurance of

each other’s identity

SMU CSE 5349/7349 5

Simple Challenge-Response AP

1. A B: Na

2. B A: { Na }kab

One way protocol using shared secret key

SMU CSE 5349/7349 6

Mutual Authentication Using

Needham-Schroeder (shared key) • M1 A -> S A, B, Na

• M2 S -> A EKas{Na , B, Kab, EKbs{Kab, A} }

• M3 A -> B EKbs{Kab, A}

• M4 B -> A EKab{Nb}

• M5 A-> B EKab{Nb-1}

– Na is a random value chosen by A, Nb random chosen by B

SMU CSE 5349/7349 7

NS – Public Key

• KDC has well known public key• B’s public received from KDC• Challenge – response as before

– We saw this in last class

SMU CSE 5349/7349 8

Attacks on AP

• Crypto system– We have seen many of them

• Protocol– Replay– Oracle session– Parallel session

SMU CSE 5349/7349 9

SMU CSE 5349/7349 10

SMU CSE 5349/7349 11

Fix for Replay Attack

• Use time stamps– Needs securely synchronised clocks

to prevent replay – not trivial– Drift window– Log of recent messages within the

window– Logical time stamps?

SMU CSE 5349/7349 12

Digital Signature Algorithms

SMU CSE 5349/7349 13

Need for DS

• No complete trust between the sender and the receiver

• Properties:– Able to verify the author, time– Authenticate the content at time of

signature– Signature verifiable by a third party

• Direct and arbitrated

SMU CSE 5349/7349 14

Use of RSA• When using RSA for both encryption and

authentication: – Use the senders private key to sign the

message – Use the recipients public key to encrypt the

message

• RSA can be used without increasing message size

• More commonly use a hash function to create a digest which is then signed – Send this signed digest separate

SMU CSE 5349/7349 15

DSA (Digital Signature Algorithm)

• US Federal Govt. approved signature scheme – used with SHA hash algorithm

• Designed by NIST & NSA in early 90's • DSA is the algorithm, DSS is the standard • DSA is a variant on the ElGamal and

Schnorr algorithms – Creates a 320 bit signature– Security again rests on difficulty of

computing discrete logarithms – Has been quite widely accepted

SMU CSE 5349/7349 16

Keyed Hash Functions

• All the above signature schemes involve public key methods – Cost and size overheads

• Have a need for a private key signature scheme – Use a fast hash function

• Include a key along with the message:– KeyedHash = Hash(Key|Message) – KeyedHash = Hash(Key1|Hash(Key2|

Message))

SMU CSE 5349/7349 17

HMAC

• Use a keyed hash function HMACK = Hash((K+ XOR opad)||Hash((K+

XOR ipad)||M)) – where K+ is the key padded out to size – opad, ipad are specified padding values

• Security is directly related to the security of the underlying hash

• Any of MD5, SHA-1, RIPEMD-160 hash algorithms can be used

SMU CSE 5349/7349 18

Kerberos

SMU CSE 5349/7349 19

Kerberos

• Trusted 3rd party authentication scheme.

• Assumes that hosts are not trustworthy.

• Requires that each client (each request for service) prove its identity.

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

Part of project Athena (MIT)

SMU CSE 5349/7349 20

Kerberos Design

• User must identify itself once at the beginning of a session• Every user has a password.

• Every service has a password.

• The only entity that knows all the passwords is the Authentication Server

• Passwords are never sent across the network in clear-text (or stored in memory)

SMU CSE 5349/7349 21

ServerServerServerServerServerServerServerServer

ServerServerServerServerServerServerServerServer

KerberosKerberosDatabaseDatabase

Ticket GrantingTicket Granting ServerServer

Ticket GrantingTicket Granting ServerServer

AuthenticationAuthentication ServerServer

AuthenticationAuthentication ServerServer

WorkstationWorkstationWorkstationWorkstation

SMU CSE 5349/7349 22

Components

• Encryption• Current Kerberos implementations (v4) use DES, although

Kerberos V5 has hooks so that other algorithms can be used

• Tickets• Each request for a service requires a ticket.

• A ticket provides a single client with access to a single server

• Tickets are dispensed by the “Ticket Granting Server” (TGS), which has knowledge of all the encryption keys

• Tickets are meaningless to clients, they simply use them to gain access to servers.

SMU CSE 5349/7349 23

Components - Tickets (cont’d)

• The TGS seals (encrypts) each ticket with the secret encryption key of the server.

• Sealed tickets can be sent safely over a network - only the server can make sense out of it.

• Each ticket has a limited lifetime (a few hours)

• Ticket Contents• Client name (user login name)

• Server name

• Client Host network address

• Session Key for Client/Server

• Ticket lifetime

• Creation of timestamp

SMU CSE 5349/7349 24

Components -Session Key

•Random number that is specific to a session.

•Session Key is used to seal client requests to server

•Session Key can be used to seal responses (application specific usage)

SMU CSE 5349/7349 25

Authenticators

• Authenticators prove a client’s identity.

• Includes:– Client user name.– Client network address.– Timestamp.

• Authenticators are sealed with a session key.

SMU CSE 5349/7349 26

Bootstrap

• Each time a client wants to contact a server, it must first ask the 3rd party (TGS) for a ticket and session key.

• In order to request a ticket from the TGS, the client must already have a TG ticket and a session key for communicating with the TGS

SMU CSE 5349/7349 27

Authentication Server

• The client sends a plaintext request to the AS

asking for a ticket it can use to talk to the TGS.

• Request:– login name– TGS name

Since this request contains only well-known names, it does not need to be sealed.

SMU CSE 5349/7349 28

Authentication Server• The AS finds the keys corresponding to the

login name and the TGS name.

• The AS creates a ticket:– login name

– TGS name– client network address

– TGS session key

• The AS seals the ticket with the TGS secret key.

SMU CSE 5349/7349 29

Authentication Server Response• The AS also creates a random session key for

the client and the TGS to use.

• The session key and the sealed ticket are sealed with the user (login name) secret key.

TGS session key

Ticket:login nameTGS namenet addressTGS session key

Sealed with user keySealed with user key

Sealed with TGS keySealed with TGS key

SMU CSE 5349/7349 30

Accessing the TGS

• The client decrypts the message using the user’s password as the secret key.

• The client now has a session key and ticket that can be used to contact the TGS.

• The client cannot see inside the ticket, since the client does not know the TGS secret key.

SMU CSE 5349/7349 31

• When a client wants to start using a server (service), the client must first obtain a ticket.

• The client composes a request to send to the TGS:

Accessing a Server

TGS Ticket

Authenticator

Server Name

sealed withsealed withTGS keyTGS key

sealed withsession key

SMU CSE 5349/7349 32

TGS response• The TGS decrypts the ticket using its secret key.

Inside is the TGS session key.

• The TGS decrypts the Authenticator using the session key.

• The TGS check to make sure login names, client addresses and TGS server name are all OK.

• TGS makes sure the Authenticator is recent.

SMU CSE 5349/7349 33

TGS Response

Once everything checks out - the TGS:

• Builds a ticket for the client and requested server. The ticket is sealed with the server key.

• Creates a session key

• Seals the entire message with the TGS session key and sends it to the client.

SMU CSE 5349/7349 34

Client Accesses Server

• The client now decrypts the TGS response using the TGS session key.

• The client now has a session key for use with the new server, and a ticket to use with that server.

• The client can contact the new server using the same format used to access the TGS.

SMU CSE 5349/7349 35

Requirements

• Secure• Reliable• Transparent• Scalable

SMU CSE 5349/7349 36

Problems

• Single point of failure– Denial-of-service attack

• Traffic• Reliability will compromise security