authentication applications - chapter 14 kerberos x.509 directory authentication (s/mime)

AUTHENTICATION APPLICATIONSAUTHENTICATION APPLICATIONS - Chapter 14 - Chapter 14

• Kerberos

• X.509 Directory Authentication (S/MIME)

SERVER ATTACKSSERVER ATTACKS

• B[A] : Pretend

• B A: Impersonate

• B(AServer): Eavesdrop/Replay

W/station W/station

W/station

Server

W/station W/station

W/station

Server

CENTRALISED AUTHENTICATIONCENTRALISED AUTHENTICATION

Symmetric Key - YES

Public Key - NO

W/station Server

W/station

CentralAuth.

K

KERBEROSKERBEROS

Two Versions Version 4. Version 5. – Draft Internet Standard

KERBEROSKERBEROS• Secure no eavesdropper / user impersonation

• Reliable backup / critical

• Transparent user unaware / password

• Scalable large number of clients

KERBEROSKERBEROS

Trusted Third-Party Authentication

Uses Needham/Schroeder scheme

Fig 7.9 and pp. 305 - 308

KERBEROS V4KERBEROS V4

Uses DES Complicated!

To analyse: Simple More Secure V4 Auth.Dialogue Dialogue Dialogue

SIMPLE DIALOGUESIMPLE DIALOGUE

Impersonations: Server Confirms Client ID

Authentication Server (AS) contains User Passwords (centralised) Unique Server Keys

SIMPLE DIALOGUESIMPLE DIALOGUE1. C IDC || PC || IDV AS

2. AS Ticket C

3. C IDC || Ticket V

Ticket = EKV[ IDC || ADC || IDV ]

C : client AS : authentication serverV : server ADC : client address (ticket only valid if from C)PC : client password

MORE SECURE DIALOGUEMORE SECURE DIALOGUE

Re-usable Tickets?

But different tickets for every server

Solution:

Use Ticket Granting Server (TGS)

MORE SECURE DIALOGUEMORE SECURE DIALOGUEOnce/Logon 1. C IDC || IDTGS AS 2. AS EKC

[TicketTGS] C (KC from users password)

Once/Service 3. C IDC || IDV || TicketTGS TGS 4. TGS TicketV C

Once/Service Session 5. C IDC || TicketV V

TicketTGS = EKTGS[IDC || ADC || IDTGS || TS1 || lifetime1]

TicketV = EKV[IDC || ADC || IDV || TS2 || lifetime2]

ADVANTGAGES of MORE SECUREADVANTGAGES of MORE SECURE DIALOGUE DIALOGUE

Password NOT plaintext instead, pwd sent via KC

Uses Multiple Service-Granting Tickets

One Problem: TicketTGS could be captured

Solution: TicketTGS includes timestamp TS and lifetime

MORE SECURE DIALOGUE MORE SECURE DIALOGUE WEAKNESSES WEAKNESSES

1. Short lifetime too many password requests

Long lifetime replay attacks

2. False servers

VERSION 4. AUTHENTICATION VERSION 4. AUTHENTICATION DIALOGUE DIALOGUE

Table 14.1 – ProtocolTable 14.2 – Rationale

1. Protect from Captured Tickets:

AS key Client Client key TGS

key TGS prove ID

key is Kc,TGS

VERSION 4.VERSION 4.Note: (1) TS1

(2) TS2, lifetime2 (3) Authenticator – use once – short life (authenticates ticket sender as owner)

After complete dialogue,

Client : Server share secret key

KERBEROS SERVER REQUIRESKERBEROS SERVER REQUIRES

• User IDs

• Hashed Passwords

• Symmetric Server Keys

(registered servers)

KERBEROS OVERVIEW

A uthenticationServer (A S)

T icket-gr anting

Server (T G S)

once peruser logonsession

1. U ser logs on toworkstation andrequests service on host.

3. W orkstation promptsuser for password anduses password to decryptincoming message, thensends ticket andauthenticator thatcontains user's name,netw ork address, andtime to T G S.

once pertype of service 4. T G S decrypts ticket and

authenticator, verifies request,then creates ticket for requestedserver.

K er ber os

5. W orkstation sendsticket and authenticatorto server.

6. Server verifies thatticket and authenticatormatch, then grants accessto service. I f mutualauthentication isrequired, server returnsan authenticator.

once perservice session

F igur e 14.1 O ver view of K er ber os

2. A S verifies user's access right indatabase, creates ticket-granting ticketand session key . R esults are encryptedusing key derived from user's password.

INTER-REALM AUTHENTICATIONINTER-REALM AUTHENTICATION

Two realms share secret key (mutually registered) - needs mutual trust (Fig 14.2)Problem: Does not scale well to many realms

Nrealms N(N-1) secure key 2 exhanges

INTER-REALM AUTHENTICATION

A S

T G S

K erberosC lient

R ealm A

A S

T G S

K erberos

ServerR ealm B

7. r

eq

ue

st r

em

ote

se

rv

ice

F igur e 14.2 R equest for Ser vice in A nother R ealm

KERBEROS 4 PROBLEMS,KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS KERBEROS 5 SOLUTIONS1. Encryption System Dependence V4: (DES,export) V5: Ciphertext tagged with encryption id - keys tagged with type/length2. Internet Protocol Dependence V4: requires IP addresses V5: addresses tagged with type/length (IP/ISO)3. Message Byte Ordering V4: tagged message with ordering V5: Abstract Syntax Notation One Basis Encoding Rules

KERBEROS 4 PROBLEMS,KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS KERBEROS 5 SOLUTIONS

4. Ticket Lifetime V4: 8-bit, 5 minute units, Max = 1280 minutes V5: Start time/End time – arbitrary5. Authentication Forwarding V4: NO Credential Forwarding V5: Credential Forwarding6. Inter-Realm Authentication V4: O(N2) keys V5: Fewer keys

KERBEROS 4 PROBLEMS,KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS (Tech) KERBEROS 5 SOLUTIONS (Tech)

1. Double Encryption ((2), (4) of Table 14.1) V4: Yes V5: Second encryption omitted2. PCBC Encryption V4: Nonstandard DES mode, PCBC (vulnerable), for integrity check V5: Explicit, separate integrity + CBC mode3. Session Keys V4: Replay risk using repeated ticket V5: Subsession key. Once only

KERBEROS 4 PROBLEMS,KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS (tech) KERBEROS 5 SOLUTIONS (tech)

4. Password Attacks V4: Vulnerable Keypassword Decrypt by guessing passwords V5: Vulnerable Pre-authentication makes attacks more difficult

KERBEROS 5 AUTHENTICATIONKERBEROS 5 AUTHENTICATION DIALOGUE DIALOGUE

Compare Tables 14.1 and 14.3

(1),(3) new: Realm, Options (flags), Times, Nonce Times are client requests for ticket time settings

(5) new: Optional Mutual Authentication

(6) new: No timestamp needed - use keys instead

X.509 AUTHENTICATIONX.509 AUTHENTICATION

Directory – database : network adddress , certificate,…etc

Certificate: CA = EKRauth

[T,IDA,KUA]

(RSA recommended)

Used for S/MIME, IPSec, SSL/TLS, and SET

CERTIFICATE DIRECTORYCERTIFICATE DIRECTORY

CA or user (trusted)

Directory

Certificate Fig 14.3a - formats

Certificates unforgeable

Directory of certificates used to distribute authentic user public keys

CERTIFICATE DIRECTORY

C ertificateSer ial Number

V ersion

I ssuer Name

Signatur ealgor ithmidentifier

Subject Name

E xtensions

I ssuer U niqueIdentifier

Subject U niqueIdentifier

algor ithm

par am eters

n ot b efor e

algor ithmsparameter s

key

algor ithmsparameter sencr ypted

(a) X .509 C er tif icate

not after

Subject'spublic key

info

Signatur e

F igure 14.3 X .509 F or mats

P er iod ofvalidity

Ve

rs

ion

1

Ve

rs

ion

2

Ve

rs

ion

3

all

ve

rs

ion

s

I ssuer Name

T his U pdate Date

Next U pdate Date

¥¥¥

Signatur ealgor ithmidentifier

algor ithm

par am eters

u ser cer tificate ser ial #

(b) C er tif icate R evocation L ist

r evocation d ate

algor ithmsparameter sencr ypted

Signatur e

R evok edcer tificate

u ser cer tificate ser ial #

r evocation d ateR evok ed

cer tificate

TWO CAsTWO CAs

AB

Cert X2

Cert B

EKR1[T,ID1,KU2]

EKR2[T,IDB,KUB]

CA2(KU2)CA1(KU1)

X1<<X2>>X2<<B>>

A wishes toobtain B’s publicsecurely via twoaccesses to thedirectory.A initially has cert. from X1

B initially has cert. from X2

Having X1’s pub. key gives access to X2’s pub. keyHaving X2’s pub. key gives access to B’s pub. key

X.509 CA HIERARCHYU

V

W Y

Z

B

X

C A

U <<V >>V <<U >>

V <<W >>W <<V >>

V <<Y >>Y <<V >>

W <<X >>X <<W >>X <<Z >>

Y <<Z >>Z <<Y >>Z <<X >>

X <<C >> X <<A >> Z<<B >>

F igur e 14.4 X .509 C A H ier ar chy: a H ypothetical E xample

CHAIN OF CERTIFICATESCHAIN OF CERTIFICATESHierarchy : Fig 14.4Forward Certificates : e.g. W<<X>> cert of X generated by W

Reverse Certificates : e.g. X<<W>> cert of W generated by X

e.g. X<<W>>W<<V>>V>>Y>>Y<<Z>>Z<<B>> result: A recovers B’s public key

CERTIFICATE REVOCATIONCERTIFICATE REVOCATION1.User secret key compromised

2. User no longer certified

3. CA’s certificate compromised

each CA has Certificate Revocation List (CRL)

X.509 AUTHENTICATIONX.509 AUTHENTICATIONThree alternatives : a) One-Way Auth. – IDA, message from A, message is for B, integrity/originality of message

b) Two-Way Auth. – a) plus IDB, reply from B, integrity/originality of reply

c) Three-Way Auth. – b) plus signed nonce – to avoid t/stamps - used when clocks not synchronised

X.509 AUTHENTICATION

A B

(c) T hr ee-way authentication

A B

(b) T wo-way authentication

A B

(a) O ne-way authentication

F igur e 14.5 X .509 Strong A uthentication P r ocedur es

1. A {tA , r A , ID B , sgnD ata, E K U b[K ab]}

1. A {tA , r A , ID B , sgnD ata, E K U b[K ab]}

1. A {tA , r A , ID B , sgnD ata, E K U b[K ab]}

3. A {r B }

2. B{t B , r B , I D A , r A , sgnD ata, E K U a[K ba]}

2. B{t B , r B , I D A , r A , sgnD ata, E K U a[K ba]}

ENCRYPTION KEY FROM PASSWORD-

1 character

-s[1]

-s[2]

¥ ¥ ¥

¥ ¥ ¥

password in7-bit A SC I I

(n characters)

flattened bitstream (7 ´ n bits)

(a) C onvert password to bit stream

s[0]

(b) C onvert bit stream to input key

fanfold onto56 bits

bitw ise X O R

64-bitinput key K pw

56 bits

K pw K pw K pw

s[0] through s[7] +

s[8] through s[15]

D E S D E S D E S

+

s[n-8] through s[n Ð 1]

output keyK c

(c) G enerate D E S C B C checksum of password

F igur e 14.6 G ener ation of E ncr yption K ey from P asswor d

PCBC MODET ime = 1

P 1I V

C 1(a) E ncryption

DE SE ncryptK

+

T ime = 2P 2

C 2

DE SE ncryptK

+

T ime = NP N

C N

DE SE ncryptK

+

¥ ¥ ¥

C 1

I V

P 1(b) Decryption

DE SDecryptK

+

C 2

P 2

DE SDecryptK

+

C N

P N

DE SDecryptK

+¥ ¥ ¥

F igur e 14.7 P r opagating C ipher B lock C hain ing (P C B C ) M ode

+ +

P N -1

C N -1

+ +

C N-1

P N -1