1. Computer and Network Security
CSEN 1001
Computer and Network Security
Amr El Mougy
Alaa Gohar
Heba Anwar
**Slides are attributed to William Stallings

2. Lecture (9)
User Authentication

3. User Authentication fundamental security building block
basis of access control & user accountability
is the process of verifying an identity claimed by or for a system entity
has two steps:
identification - specify identifier
verification - bind entity (person) and identifier
distinct from message authentication

4. Means of User Authentication
four means of authenticating user's identity
based one something the individual
knows - e.g. password, PIN
possesses - e.g. key, token, smartcard
is (static biometrics) - e.g. fingerprint, retina
does (dynamic biometrics) - e.g. voice, sign
can use alone or combined
all can provide user authentication
all have issues

5. Authentication Protocols
used to convince parties of each others identity and to exchange session keys
may be one-way or mutual
key issues are
confidentiality – to protect session keys
timeliness – to prevent replay attacks

6. Replay Attacks where a valid signed message is copied and later resent
simple replay
repetition that can be logged
repetition that cannot be detected
backward replay without modification
countermeasures include
use of sequence numbers (generally impractical)
timestamps (needs synchronized clocks)
challenge/response (using unique nonce)

7. One-Way Authentication
required when sender & receiver are not in communications at same time (eg. )
have header in clear so can be delivered by system
may want contents of body protected & sender authenticated

8. Using Symmetric Encryption
as discussed previously can use a two-level hierarchy of keys
usually with a trusted Key Distribution Center (KDC)
each party shares own master key with KDC
KDC generates session keys used for connections between parties
master keys used to distribute these to them

9. Needham-Schroeder Protocol
original third-party key distribution protocol
for session between A, B mediated by KDC
protocol overview is:
1. AKDC: IDA || IDB || N1
2. KDC  A: E(Ka,[Ks||IDB||N1|| E(Kb,[Ks||IDA])])
3. A  B: E(Kb, [Ks||IDA])
4. B  A: E(Ks, [N2])
5. A  B: E(Ks, [f(N2)])
For replay attacks

10. Needham-Schroeder Protocol
used to securely distribute a new session key for communications between A & B
but is vulnerable to a replay attack if an old session key has been compromised
then message 3 can be resent convincing B that is communicating with A
modifications to address this require:
timestamps in steps 2 & 3 (Denning 81)
using an extra nonce (Neuman 93)

11. Improvement using Timestamps
protocol becomes:
1. AKDC: IDA || IDB
2. KDC  A: E(Ka,[Ks||IDB||T|| E(Kb,[Ks||IDA||T])])
3. A  B: E(Kb, [Ks||IDA||T])
4. B  A: E(Ks, [N1])
5. A  B: E(Ks, [f(N1)])
Success of this protocol relies on synchronized clocks at sender and receiver because both sides need to verify the timestamp
Vulnerable to suppress-replay attack (when the sender’s clock is ahead of recipient’s clock)

12. Improvement using Nonces
protocol becomes:
1. AB: IDA || NA
2. B KDC: IDB||NB|| E(Kb,[IDA||NA||Tb])
3. KDC  A: E(Ka, [IDB||NA||Ks||Tb])||E(Kb,[IDA||Ks||Tb])||NB
4. A  B: E(Kb,[IDA||Ks||Tb])||E(Ks, NB)
Note that the timestamp is checked only at B  suppress-replay attack is not possible

13. One-Way Authentication
use refinement of KDC to secure
since B no online, drop steps 4 & 5
protocol becomes:
1. AKDC: IDA || IDB || N1
2. KDC  A: E(Ka, [Ks||IDB||N1 || E(Kb,[Ks||IDA])])
3. A  B: E(Kb, [Ks||IDA]) || E(Ks, M)
provides encryption & some authentication
does not protect from replay attack

14. Kerberos trusted key server system from MIT
provides centralised private-key third-party authentication in a distributed network
allows users access to services distributed through network
without needing to trust all workstations
rather all trust a central authentication server
two versions in use: 4 & 5

15. Motivation for Kerberos
In an environment of distributed servers, need to authenticate clients to provide services
The following threats exist:
User gains access to a particular workstation and pretends to be another user
A user alters the network address of a workstation to appear as if sending from a different workstation
A replay attack is executed to gain access to server

16. Motivation for Kerberos
The following solutions are possible:
Rely on workstations to authenticate their clients. Here servers do not authenticate clients
The client systems authenticate themselves to servers but trust the client system with the identity of its user
Users prove their identities to the servers for each requested service. Servers also authenticate themselves to clients
First two solutions are only suitable for small systems
Kerberos uses the third approach with a Kerberos server to provide an authentication service

17. Kerberos Requirements
its first report identified requirements as:
secure
reliable
transparent
scalable
implemented using an authentication protocol based on Needham-Schroeder

18. Kerberos 4 Overview a basic third-party authentication scheme
have an Authentication Server (AS)
users initially negotiate with AS to identify self
AS provides a non-corruptible authentication credential (ticket granting ticket TGT)
have a Ticket Granting server (TGS)
users subsequently request access to other services from TGS on basis of users TGT
using a complex protocol using DES

19. Understanding Kerberos
Step 1: A Simple Authentication Dialogue
C  AS: IDc || Pc || IDv
AS  C: Ticket
C  V: IDc || Ticket
Ticket = EKv[IDc || ADc || IDv]
IDv is included in Step 3 is used for the server to verify that ticket is properly decrypted
IDc ensures that the ticket was issued for C
ADc ensures that no one can capture the ticket and send it from another workstation

20. Understanding Kerberos
Step 1: A Simple Authentication Dialogue
Problems:
User has to enter password each time a ticket is needed
If tickets are used once then password needs to be entered every time a service is requested
If tickets are reusable then the user will enter password only for a new service  still impractical
Password was sent in the clear

21. Understanding Kerberos
Step 2: Improved Authentication Dialogue
Once per user logon session:
(1) C  AS: IDC||IDtgs
(2) AS  C: E(Kc, Tickettgs)
Once per type of service: 
(3) C  TGS: IDC||IDV||Tickettgs 
(4) TGS  C: Ticketv
Once per service session: 
(5) C  V: IDC||Ticketv
Tickettgs = E(Ktgs, [IDC||ADC||IDtgs||TS1||Lifetime1])
Ticketv = E(Kv, [IDC||ADC||IDv||TS2||Lifetime2])

22. Understanding Kerberos
Step 2: Improved Authentication Dialogue
Password is not sent in the clear. It is entered at the workstation once and used to derive Kc.
The TGS is used to obtain tickets for each new service needed (no password re-entry)
The client saves these tickets (Ticketv) to authenticate the user to the server
Timestamp and lifetime are user to prevent an attacker from hijacking a workstation after a user logs off and uses the same ticket

23. Understanding Kerberos
Step 2: Improved Authentication Dialogue
Problems:
Lifetime of ticket-granting ticket is an issue. Very short  user enter passwords repeatedly. Very long replay attacks become possible (attacker waits for user to log off and hijacks the workstation and sends the message in Step 3. Same for service-granting ticket
Servers should authenticate themselves to clients or else someone may impersonate the servers
Solution: let AS provide Client and TGS with info that they can use to authenticate each other

24. Kerberos Dialogue (1) C  AS: IDc||IDtgs||TS1
(2) ASC: E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs]) 
Tickettgs = E(Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2])
Authentication Service Exchange to obtain ticket-granting ticket
(3) C  TGS: IDv||Tickettgs||Authenticatorc
(4) TGS  C: E(Kc,tgs, [Kc,v||IDv||TS4||Ticketv]) 
Tickettgs = E(Ktgs, [Kc,tgs||IDC||ADC||IDtgs||TS2||Lifetime2])
Ticketv = E(Kv, [Kc,v||IDC||ADC||IDv||TS4||Lifetime4])
Authenticatorc = E(Kc,tgs, [IDC||ADC||TS3])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket
(5) C  V: Ticketv||Authenticatorc
(6) V  C: E(Kc,v, [TS5 + 1]) (for mutual authentication) 
Ticketv = E(Kv, [Kc,v||IDc||ADc||IDv||TS4||Lifetime4])
Authenticatorc = E(Kc,v,[IDc||ADC||TS5])
(c) Client/Server Authentication Exchange to obtain service

25. Kerberos 4 Overview

26. Kerberos Realms a Kerberos environment consists of:
a Kerberos server
a number of clients, all registered with server
application servers, sharing keys with server
this is termed a realm
typically a single administrative domain
if have multiple realms, their Kerberos servers must share keys and trust

27. Kerberos Version 5 developed in mid 1990’s
specified as Internet standard RFC 1510
provides improvements over v4
addresses environmental shortcomings
encryption alg, network protocol, byte order, ticket lifetime, authentication forwarding, interrealm auth
and technical deficiencies
double encryption, non-std mode of use, session keys, password attacks

28. Kerberos Version 5 Dialogue

29. Remote User Authentication
previously saw use of public-key encryption for session key distribution
assumes both parties have other’s public keys
may not be practical
have Denning protocol using timestamps
uses central authentication server (AS) to provide public-key certificates
requires synchronized clocks
have Woo and Lam protocol using nonces

30. Denning AS Protocol
Does not assume that parties know each other’s public key
Denning presented the following:
1. A -> AS: IDA || IDB
2. AS -> A: EPRas[IDA||PUa||T] || EPRas[IDB||PUb||T]
3. A -> B: EPRas[IDA||PUa||T] || EPRas[IDB||PUb||T] || EPUb[EPRa[Ks||T]]
note session key is chosen by A, hence AS need not be trusted to protect it
timestamps prevent replay but require synchronized clocks