Date post: | 17-Dec-2015 |
Category: |
Documents |
Upload: | harriet-hicks |
View: | 234 times |
Download: | 0 times |
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