CT UNIT 5 Session 3.ppt User authentication and kerberos protocol

This ppt is about cryptography techniques user authentication

1. DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
COURSE CODE: U21CS601
COURSE TITLE : CRYPTOGRAPHY TECHNIQUES
FACULTY NAME : Dr.A.BALAMURUGAN
ACADEMIC YEAR :2023 –2024 (EVEN SEM)

2. UNIT V KEY MANAGEMENT AND USER
AUTHENTICATION
Keymanagementanddistribution–X.509certificate–Publickey
infrastructure–Userauthentication–Kerberosprotocol
CO05:Constructkeymanagementanduserauthentication
protocolsforprovidingkeysharingandauthenticationservices
(Apply)

3. UNIT -V
SESSION 1 -Key management and distribution
SESSION 2 -X.509 certificate –Public key infrastructure
SESSION 3 -User authentication –Kerberos protocol

4. SESSION-3
User authentication –Kerberos
protocol

5. User-Authentication
•Theprocessofverifyingwhetherauser,application,orprocess
actingonbehalfofauserisindeedtheentityitclaimstobe.
•Authenticationtechnologyprovidesaccesscontrolforsystems
bycheckingtoseeifauser’scredentialsmatchthecredentials
inadatabaseofauthorizedusersorinadataauthentication
server
•Authenticationenablesorganizationstokeeptheirnetworks
securebypermittingonlyauthenticatedusers(orprocesses)to
accessitsprotectedresources
•Userauthenticationisdistinctfrommessageauthentication
•Messageauthenticationisaprocedurethatallowscommunicating
partiestoverifythatthecontentsofareceivedmessagehavenot
beenalteredandthatthesourceisauthentic

6. Authentication Principles
•Digitalidentity:
•Theuniquerepresentationofasubjectengagedinanonlinetransaction
•Therepresentationconsistsofanattributeorsetofattributesthat
uniquelydescribeasubjectwithinagivencontextofadigitalservice,but
doesnotnecessarilyuniquelyidentifythesubjectinallcontexts
•Identityproofing:
•Establishesthatasubjectiswhotheyclaimtobetoastatedlevelof
certitude
•Thisprocessinvolvescollecting,validating,andverifyinginformation
aboutaperson
•Digitalauthentication:
•Theprocessofdeterminingthevalidityofoneormoreauthenticatorsusedtoclaim
adigitalidentity
•Authenticationestablishesthatasubjectattemptingtoaccessadigitalserviceisin
controlofthetechnologiesusedtoauthenticate
•Successfulauthenticationprovidesreasonablerisk-basedassurancesthatthe
subjectaccessingtheservicetodayisthesameasthesubjectthatpreviously
accessedtheservice

8. Means of User Authentication

9. Mutual Authentication
Protocolswhichenablecommunicatingpartiestosatisfy
themselvesmutuallyabouteachother’sidentityandto
exchangesessionkeys
Central to the
problem of
authenticated
key exchange
are two issues:
Confidentiality
•Essential identification
and session-key
information must be
communicated in
encrypted form
•This requires the prior
existence of secret or
public keys that can be
used for this purpose
Timeliness
•Important because of the
threat of message replays
•Such replays could allow an
opponent to:
•compromise a session key
•successfully impersonate
another party
•disrupt operations by
presenting parties with
messages that appear
genuine but are not

10. Replay Attacks
1.Thesimplestreplayattackisoneinwhichtheopponentsimply
copiesamessageandreplaysitlater
2.Anopponentcanreplayatimestampedmessagewithinthevalid
timewindow
3.Anopponentcanreplayatimestampedmessagewithinthevalid
timewindow,butinaddition,theopponentsuppressestheoriginal
message;thus,therepetitioncannotbedetected
4.Anotherattackinvolvesabackwardreplaywithoutmodificationand
ispossibleifsymmetricencryptionisusedandthesendercannot
easilyrecognizethedifferencebetweenmessagessentand
messagesreceivedonthebasisofcontent

11. Approaches to Coping With Replay Attacks
•Attachasequencenumbertoeachmessageusedinanauthentication
exchange
•Anewmessageisacceptedonlyifitssequencenumberisintheproperorder
•Difficultywiththisapproachisthatitrequireseachpartytokeeptrackofthelast
sequencenumberforeachclaimantithasdealtwith
•Generallynotusedforauthenticationandkeyexchangebecauseofoverhead
•Timestamps
•Requiresthatclocksamongthevariousparticipantsbe
synchronized
•PartyAacceptsamessageasfreshonlyifthemessage
containsatimestampthat,inA’sjudgment,isclose
enoughtoA’sknowledgeofcurrenttime
•Challenge/response
•PartyA,expectingafreshmessagefromB,firstsendsB
anonce(challenge)andrequiresthatthesubsequent
message(response)receivedfromBcontainthecorrect
noncevalue

12. Kerberos
•AuthenticationservicedevelopedaspartofProjectAthenaatMIT
•Aworkstationcannotbetrustedtoidentifyitsuserscorrectlytonetwork
services
•Ausermaygainaccesstoaparticularworkstationandpretendtobeanotheruser
operatingfromthatworkstation
•Ausermayalterthenetworkaddressofaworkstationsothattherequestssent
fromthealteredworkstationappeartocomefromtheimpersonatedworkstation
•Ausermayeavesdroponexchangesanduseareplayattacktogainentrancetoa
serverortodisruptoperations
•Kerberosprovidesacentralizedauthenticationserver
whosefunctionistoauthenticateuserstoserversand
serverstousers
•Reliesexclusivelyonsymmetricencryption,makingnouse
ofpublic-keyencryption

13. Kerberos Requirements
The first published report on Kerberos listed the following requirements:
•Ideally, the user should not
be aware that authentication
is taking place beyond the
requirement to enter a
password
•The system should be
capable of supporting
large numbers of clients
and servers
•Should be highly reliable and
should employ a distributed
server architecture with one
system able to back up another
•A network
eavesdropper should
not be able to obtain
the necessary
information to
impersonate a user
Secure Reliable
TransparentScalable

14. Kerberos Version 4
•MakesuseofDEStoprovidetheauthenticationservice
•Authenticationserver(AS)
•Knowsthepasswordsofallusersandstorestheseinacentralized
database
•Sharesauniquesecretkeywitheachserver
•Ticket
•CreatedoncetheASacceptstheuserasauthentic;containstheuser’s
IDandnetworkaddressandtheserver’sID
•EncryptedusingthesecretkeysharedbytheASandtheserver
•Ticket-granting server (TGS)
•Issues tickets to users who have been authenticated to AS
•Each time the user requires access to a new service the client applies to
the TGS using the ticket to authenticate itself
•The TGS then grants a ticket for the particular service
•The client saves each service-granting ticket and uses it to authenticate
its user to a server each time a particular service is requested

15. Authentication
server
Ticket-
granting
server (TGS)
Host/
application
server
request ticket-
granting ticket
once per
user logon
session
1. User logs on to
workstation and
requests service on host
3. Workstation prompts
user for password to decrypt
incoming message, then
send ticket and
authentictor that contains
user’s name, network
address and time to TGS.
ticket + session key
request service-
granting ticket
ticket + session key
once per
type of service
4. TGS decrypts ticket and
authenticator, verifies request
then creates ticket for requested
application server
Kerberos
5. Workstation sends
ticket and authenticator
to host.
6. Host verifies that
ticket and authenticator
match, then grants access
to service. If mutual
authentication is
required, server returns
an authenticator.
r
e
q
u
e
s
t

s
e
r
v
i
c
e
p
r
o
v
i
d
e

s
e
r
v
e
r
a
u
t
h
e
n
t
i
c
a
t
o
r
once per
service session
Figure 16.3 Overview of Kerberos
2. AS verifies user's access right in
database, creates ticket-granting ticket
and session key. Results are encrypted
using key derived from user's password.

16. Figure 16.4 Kerberos Exchanges
Client
Client authentication
IDc || IDtgs || TS1
Tickettgs, server ID, and client authentication
IDv || Tickettgs || Authenticatorc
Shared key and ticket
E(Kc,tgs, [K
c,v
|| IDv || TS4 || Ticketv])
Ticketv and client authentication
Ticketv || Authenticatorc
Service granted
E(Kc,v, [TS5 + 1])
Shared key and ticket
E(Kc, [Kc,tgs || IDtgs || TS2 ||
Lifetime2 || Tickettgs])
Authentication
server (AS)
Ticket-granting
server (TGS)
Service
provider

17. Table 16.2 Summary of Kerberos Version 4 Message Exchanges


(1) C ® AS ID
c
|| ID
tgs
|| TS
1

(2) AS ® C E(K
c
, [K
c,tgs
|| ID
tgs
|| TS
2
|| Lifetime
2
|| Ticket
tgs
])
Ticket
tgs
= E(K
tgs
, [K
c,tgs
|| ID
C
|| AD
C
|| ID
tgs
|| TS
2
|| Lifetime
2
])
(a) Authentication Service Exchange to obtain ticket-granting ticket

(3) C ® TGS ID
v
|| Ticket
tgs
|| Authenticator
c

(4) TGS ® C E(K
c,tgs
, [K
c,v
|| ID
v
|| TS
4
|| Ticket
v
])
Ticket
tgs
= E(K
tgs
, [K
c,tgs
|| ID
C
|| AD
C
|| ID
tgs
|| TS
2
|| Lifetime
2
])
Ticket
v
= E(K
v
, [K
c,v
|| ID
C
|| AD
C
|| ID
v
|| TS
4
|| Lifetime
4
])
Authenticator
c
= E(K
c,tgs
, [ID
C
|| AD
C
|| TS
3
])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket

(5) C ® V Ticket
v
|| Authenticator
c

(6) V ® C E(K
c,v
, [TS
5
+ 1]) (for mutual authentication)
Ticket
v
= E(K
v
, [K
c,v
|| ID
C
|| AD
C
|| ID
v
|| TS
4
|| Lifetime
4
])
Authenticator
c
= E(K
c,v
, [ID
C
|| AD
C
|| TS
5
])
(c) Client/Server Authentication Exchange to obtain service
(Table is on page 496 in the
textbook)

21. Kerberos Realms and Multiple Kerberi
•Afull-serviceKerberosenvironmentconsistingofaKerberosserver,a
numberofclients,andanumberofapplicationserversrequiresthat:
•TheKerberosservermusthavetheuserIDandhashed
passwordsofallparticipatingusersinitsdatabase;allusersare
registeredwiththeKerberosserver
•TheKerberosservermustshareasecretkeywitheachserver;
allserversareregisteredwiththeKerberosserver
•TheKerberosserverineachinteroperatingrealmsharesa
secretkeywiththeserverintheotherrealm;thetwoKerberos
serversareregisteredwitheachother

22. Kerberos Realm
•A set of managed nodes that share the same Kerberos database
•The database resides on the Kerberos master computer system,
which should be kept in a physically secure room
•A read-only copy of the Kerberos database might also reside on
other Kerberos computer systems
•All changes to the database must be made on the master computer
system
•Changing or accessing the contents of a Kerberos database requires
the Kerberos master password

23. Kerberos Principal
•A service or user that is
known to the Kerberos
system
•Identified by its principal
name
Three parts of a principal
name
A realm
name
An
instance
name
A service
or user
name

24. Differences Between Versions 4 and 5
Version 5 is intended to address the
limitations of version 4 in two areas:
Environmental shortcomings
•Encryption system dependence
•Internet protocol dependence
•Message byte ordering
•Ticket lifetime
•Authentication forwarding
•Interrealm authentication
Technical deficiencies
•Double encryption
•PCBC encryption
•Session keys
•Password attacks

25. Summary of Kerberos Version 5 Message Exchanges

(1) C ® AS Options || ID
c
|| Realm
c
|| ID
tgs
|| Times || Nonce
1

(2) AS ® C Realm
c
|| ID
C
|| Ticket
tgs
|| E(K
c
, [K
c,tgs
|| Times || Nonce
1
|| Realm
tgs
|| ID
tgs
])
Ticket
tgs
= E(K
tgs
, [Flags || K
c,tgs
|| Realm
c
|| ID
C
|| AD
C
|| Times])
(a) Authentication Service Exchange to obtain ticket-granting ticket
(3) C ® TGS Options || ID
v
|| Times || || Nonce
2
|| Ticket
tgs
|| Authenticator
c

(4) TGS ® C Realm
c
|| ID
C
|| Ticket
v
|| E(K
c,tgs
, [K
c,v
|| Times || Nonce
2
|| Realm
v
|| ID
v
])
Ticket
tgs
= E(K
tgs
, [Flags || K
c,tgs
|| Realm
c
|| ID
C
|| AD
C
|| Times])
Ticket
v
= E(K
v
, [Flags || K
c,v
|| Realm
c
|| ID
C
|| AD
C
|| Times])
Authenticator
c
= E(K
c,tgs
, [ID
C
|| Realm
c
|| TS
1
])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket
(5) C ® V Options || Ticketv || Authenticatorc
(6) V ® C EKc,v
[ TS2 || Subkey || Seq# ]
Ticket
v
= E(K
v
, [Flags || K
c,v
|| Realm
c
|| ID
C
|| AD
C
|| Times])
Authenticator
c
= E(K
c,v
, [ID
C
|| Realm
c
|| TS
2
|| Subkey || Seq#])
(c) Client/Server Authentication Exchange to obtain service

26. Mutual Authentication
Public-key encryption
for session key
distribution
•Assumes each of the
two parties is in
possession of the
current public key of
the other
•May not be practical
to require this
assumption
Denning protocol
using timestamps
•Uses an
authentication
server (AS) to
provide public-key
certificates
•Requires the
synchronization of
clocks
Woo and Lam makes
use of nonces
•Care needed to
ensure no protocol
flaws

27. One-Way Authentication
•Involves a single transfer of information from one user (A)
intended for another (B)
•In its simplest form, it would establish the identity of A, the identity
of B, and establish that some sort of authentication token actually
was generated by A and actually was intended to be sent to B
•An email message is an example of an application that lends itself to one-way
authentication
•For confidentiality encrypt message with a one-time secret key; A
also encrypts this one-time key with B’s public-key
•Only B will be able to use the corresponding private key to recover the one-time key
and then use that key to decrypt the message
•This scheme is more efficient than simply encrypting the entire message with B’s
public key

28. One-Way Authentication
•If authentication is the primary concern, a digital
signature may suffice
•This method guarantees that A cannot later deny having sent the message
•To counter fraud both the message and signature can be encrypted with the recipient’s
public key
•In addition to the message, A sends B the signature encrypted with A’s
private key and A’s certificate encrypted with the private key of the
authentication server
•The recipient of the message first uses the certificate to obtain the
sender’s public key and verify that it is authentic and then uses the
public key to verify the message itself
•If confidentiality is required, then the entire message can be encrypted
with B’s public key
•Alternatively, the entire message can be encrypted with a one-time
secret key; the secret key is also transmitted, encrypted with B’s public
key