authentication applications - chapter 14
DESCRIPTION
AUTHENTICATION APPLICATIONS - Chapter 14. Kerberos X.509 Directory Authentication (S/MIME). SERVER ATTACKS. B[A] : Pretend B A: Impersonate B(AServer): Eavesdrop/Replay. CENTRALISED AUTHENTICATION. Symmetric Key - YES - PowerPoint PPT PresentationTRANSCRIPT
AUTHENTICATION APPLICATIONS - Chapter 14
• Kerberos
• X.509 Directory Authentication (S/MIME)
SERVER 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 AUTHENTICATION
Symmetric Key - YES
Public Key - NO
W/station Server
W/station
CentralAuth.
K
KERBEROS
Two Versions Version 4. Version 5. – Draft Internet Standard
KERBEROS
• Secure no eavesdropper / user impersonation
• Reliable backup / critical
• Transparent user unaware / password
• Scalable large number of clients
KERBEROS
Trusted Third-Party Authentication
Uses Needham/Schroeder scheme
Fig 7.9
KERBEROS V4
Uses DES Complicated!
To analyse: Simple More Secure V4 Auth.Dialogue Dialogue Dialogue
SIMPLE DIALOGUE
Impersonations: Server Confirms Client ID
Authentication Server (AS) contains User Passwords (centralised) Unique Server Keys
SIMPLE DIALOGUE
1. 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 DIALOGUE
Re-usable Tickets?
But different tickets for every server
Solution:
Use Ticket Granting Server (TGS)
MORE 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 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
MORE SECURE DIALOGUE WEAKNESSES
1. Short lifetime too many password requests
Long lifetime replay attacks
2. False servers
VERSION 4. AUTHENTICATION 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.
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 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 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 5 SOLUTIONS
1. 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 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 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 5 SOLUTIONS (tech)
4. Password Attacks V4: Vulnerable Keypassword Decrypt by guessing passwords V5: Vulnerable Pre-authentication makes attacks more difficult
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
X.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 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 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 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 REVOCATION1.User secret key compromised
2. User no longer certified
3. CA’s certificate compromised
each CA has Certificate Revocation List (CRL)
X.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