AUTHENTICATION APPLICATIONS Chapter 14

1
AUTHENTICATION APPLICATIONS -
Chapter 14

• Kerberos
• X.509 Directory Authentication (S/MIME)

2
SERVER ATTACKS

• BA Pretend
• B ? A Impersonate
• B(A??Server) Eavesdrop/Replay

3
CENTRALISED AUTHENTICATION
Symmetric Key - YES Public Key
- NO
4
KERBEROS
Two Versions Version 4.
Version 5. Draft Internet Standard
5
KERBEROS

• Secure
• no eavesdropper / user impersonation
• Reliable
• backup / critical
• Transparent
• user unaware / password
• Scalable
• large number of clients

6
KERBEROS
Trusted Third-Party Authentication Uses
Needham/Schroeder scheme Fig 7.9
7
KERBEROS V4
Uses DES Complicated! To analyse
Simple More Secure V4
Auth. Dialogue ? Dialogue ? Dialogue
8
SIMPLE DIALOGUE
Impersonations Server Confirms Client
ID Authentication Server (AS)
contains User Passwords (centralised)
Unique Server Keys
9
SIMPLE DIALOGUE

• C ?IDC PC IDV AS
• AS ?Ticket C
• C ?IDC Ticket V
• Ticket EKV IDC ADC IDV
• C client AS authentication
  server
• V server ADC client address
• (ticket
  only valid if from C)
• PC client password

10
MORE SECURE DIALOGUE
Re-usable Tickets? But different tickets
for every server Solution Use Ticket
Granting Server (TGS)
11
MORE SECURE DIALOGUE
Once/Logon 1. C ?IDC
IDTGS AS 2. AS
?EKCTicketTGS 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 EKTGSIDC ADC IDTGS TS1
lifetime1 TicketV EKVIDC ADC IDV
TS2 lifetime2
12
ADVANTGAGES of MORE SECURE
DIALOGUE
Password NOT plaintext instead, pwd
confirmed via KC Uses Multiple
Service-Granting Tickets One Problem
TicketTGS could be captured Solution
TicketTGS includes timestamp TS and lifetime
13
MORE SECURE DIALOGUE
WEAKNESSES
1. Short lifetime ? too many password requests
Long lifetime ? replay attacks 2. False
servers
14
VERSION 4. AUTHENTICATION DIALOGUE
Table 14.1 Protocol Table 14.2 Rationale 1.
Protect from Captured Tickets AS ?key Client
Client ?key TGS ?key TGS
prove ID
key is Kc,TGS
15
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
16
KERBEROS SERVER REQUIRES

• User IDs
• Hashed Passwords
• Symmetric Server Keys
• (registered servers)

17
KERBEROS OVERVIEW
18
INTER-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
19
INTER-REALM AUTHENTICATION
20
KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS

• Encryption System Dependence
• V4 (DES,export)
• V5 Ciphertext tagged with encryption id
• - keys tagged with type/length
• 2. 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

21
KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS
4. Ticket Lifetime V4 8-bit, 5 minute units,
Max 1280 minutes V5 Start time/End time
arbitrary 5. Authentication Forwarding V4 NO
Credential Forwarding V5 Credential
Forwarding 6. Inter-Realm Authentication V4
O(N2) keys V5 Fewer keys
22
KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS
(Tech)

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

23
KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS
(tech)
4. Password Attacks V4 Vulnerable
Keypassword ? Decrypt by guessing
passwords
V5 Vulnerable Pre-authentication
makes attacks more
difficult
24
KERBEROS 5 AUTHENTICATION
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
25
X.509 AUTHENTICATION
Directory database network adddress ,
certificate,etc Certificate CA
EKRauthT,IDA,KUA
(RSA recommended) Used for S/MIME, IPSec,
SSL/TLS, and SET
26
CERTIFICATE DIRECTORY
Directory
Fig 14.3a - formats
CA or user ? (trusted)
Certificate
Certificates unforgeable Directory of
certificates used to distribute authentic
user public keys
27
CERTIFICATE DIRECTORY
28
TWO CAs
B
A
A wishes to obtain Bs public securely via
two accesses to the directory. A initially has
cert. from X1 B initially has cert. from
X2
EKR1T,ID1,KU2
Cert X2
EKR2T,IDB,KUB
Cert B
CA2(KU2)
CA1(KU1)
Having X1s pub. key gives access to X2s pub.
key Having X2s pub. key gives access to Bs pub.
key
? X1ltltX2gtgtX2ltltBgtgt
29
X.509 CA HIERARCHY
30
CHAIN OF CERTIFICATES
Hierarchy Fig 14.4 Forward Certificates
e.g. WltltXgtgt
cert of X generated by W Reverse
Certificates e.g. XltltWgtgt
cert of W generated
by X e.g. XltltWgtgtWltltVgtgtVgtgtYgtgtYltltZgtgtZltltBgtgt
result A recovers Bs public key
31
CERTIFICATE REVOCATION

• User secret key compromised
• User no longer certified
• 3. CAs certificate compromised
• each CA has
• Certificate Revocation List (CRL)

32
X.509 AUTHENTICATION
Three 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
33
X.509 AUTHENTICATION
34
ENCRYPTION KEY FROM PASSWORD
35
PCBC MODE