1. Authentication Applications
Chapter 4
Authentication Applications

2. Outline Threat, Vulnerability, Exploit Authentication Applications
Kerberos
X.509 Authentication Service
Recommended reading and Web Sites

3. What is a threat?
Threat – any circumstance or event that has potential to cause harm to a system or network.
Threat can be
Internal threat
External threat
It may cause destruction of data and property.
It may involve invasion of privacy

4. Vulnerability and Exploit ?
Vulnerability – Existence of weakness, design or implementation error that can lead to an unexpected, undesirable event compromising the security of the system.
Exploit – A program or technique that takes advantage of a vulnerability in software or system that can be used for breaking the security and attacking a host over the network.

5. Internal Threat
Internal threats are threats from with in the organization
These threat originate from individuals who have authorized access to the network or have an account on a server.
It can be from a disgruntled former or current employee or contractor.

6. Internal Threat
An internal user may attack a system for any number of reasons, including the following:
Data theft
Espionage
Sabotage
General malice
80% of reported security incidents involved inside abuse (CSI/FBI computer crime and security survey, 2004).

7. Internal Threat : Sniffing
One of the major internal threat is “sniffing”.
Sniffing – is the process of reading the packets that are transmitted on the network.
Example:
Passwords
Credit card numbers
TELNET, FTP SMTP ( ) packets if unencrypted can be successfully sniffed.

8. External Threat
The threat from outside the organization, who have no legitimate rights to corporate system or information.
External threats like “love bug” can create huge economic losses to corporate company with in a short time.
Types of external threats:
Social Engineering
Denial of Service attack
Virus, Worm and Trojans
Organizational attacks
Accidental security breaches
Automated attacks

9. Social Engineering Social engineering Also refer as “People hacking”
“The act of obtaining unauthorized access to a network by manipulating authorized users in to revealing their passwords and access information.”
Also refer as “People hacking”
Social engineering relies on communication skills.
Social engineering user’s often use telephone to convince.
Social engineering user’s use confidential data or information for unauthorized access to network.
Example of attack: - telephone scams, hoaxes and virus

10. Denial of Service attack
DoS is an attack designed to prevent your computer or network from operating or commucating.
Block access to resources
Flood network, degrades performance, causes server to Fail.
Result in
Loss of revenue
Prestige
Service to customer

11. Authentication Applications
developed to support application-level authentication & digital signatures
will discuss Kerberos – a private-key authentication service
discuss X a public-key directory authentication service
This chapter examines some of the authentication functions that have been developed to support application-level authentication and digital signatures.
Will first look at one of the earliest and most widely used services: Kerberos. Then examine the X.509 directory authentication service.

12. KERBEROS
In Greek mythology, a many headed dog, the guardian of the entrance of Hades

13. KERBEROS
Authentication service developed as a part of MIT’s Athena project
provides centralized 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

14. KERBEROS An open distributed environment
Any user can access services from any workstation
Several security threats exists in such an environment:
A user impersonate another user
A user may change the network address of a w/s and may make it look as another w/s
A user may eavesdrop on a session and mount a replay attack later
The first published report on Kerberos [STEI88] listed the requirements shown above. To support these requirements, Kerberos is a trusted third-party authentication service that uses a protocol based on that proposed by Needham and Schroeder [NEED78], which was discussed in Chapter 7.

15. KERBEROS : The Requirements
its first report identified requirements as:
secure
reliable
transparent
scalable
implemented using an authentication protocol based on Needham-Schroeder
The first published report on Kerberos [STEI88] listed the requirements shown above. To support these requirements, Kerberos is a trusted third-party authentication service that uses a protocol based on that proposed by Needham and Schroeder [NEED78], which was discussed in Chapter 7.

16. KERBEROS
Provides a centralized authentication server to authenticate users to servers and servers to users.
Relies on conventional encryption, making no use of public-key encryption
Two versions: version 4 and 5
Version 4 makes use of DES

17. Kerberos Version 4 Terms: C = Client AS = authentication server
V = server
IDc = identifier of user on C
IDv = identifier of V
Pc = password of user on C
ADc = network address of C
Kv = secret encryption key shared by AS an V
TS = timestamp
|| = concatenation

18. A Simple Authentication Dialogue
C  AS: IDc || Pc || IDv
AS  C: Ticket
C  V: IDc || Ticket
Ticket = EKv[IDc || Pc || IDv]

19. Version 4 Authentication Dialogue
Problems:
Lifetime associated with the ticket-granting ticket
If too short  repeatedly asked for password
If too long  greater opportunity to replay
The threat is that an opponent will steal the ticket and use it before it expires

20. Version 4 Authentication Dialogue
Authentication Service Exhange: To obtain Ticket-Granting Ticket
C  AS: IDc || IDtgs ||TS1
AS  C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]
Ticket-Granting Service Echange: To obtain Service-Granting Ticket
(3) C  TGS: IDv ||Tickettgs ||Authenticatorc
(4) TGS  C: EKc [Kc,¨v|| IDv || TS4 || Ticketv]
Client/Server Authentication Exhange: To Obtain Service
(5) C  V: Ticketv || Authenticatorc
(6) V  C: EKc,v[TS5 +1]

21. Overview of Kerberos

22. Kerberos Realms a Kerberos server
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
A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a number of application servers is referred to as a Kerberos realm. A Kerberos realm is a set of managed nodes that share the same Kerberos database, and are part of the same administrative domain. If have multiple realms, their Kerberos servers must share keys and trust each other.

23. Request for Service in Another Realm

24. Difference Between Version 4 and 5
Encryption system dependence (V.4 DES)
Internet protocol dependence
Message byte ordering
Ticket lifetime
Authentication forwarding
Interrealm authentication

25. Kerberos Encryption Techniques

26. PCBC Mode

27. Kerberos - in practice Currently have two Kerberos versions:
4 : restricted to a single realm
5 : allows inter-realm authentication, in beta test
Kerberos v5 is an Internet standard
specified in RFC1510, and used by many utilities
To use Kerberos:
need to have a KDC on your network
need to have Kerberised applications running on all participating systems
major problem - US export restrictions
Kerberos cannot be directly distributed outside the US in source format (& binary versions must obscure crypto routine entry points and have no encryption)
else crypto libraries must be reimplemented locally

28. X.509 Authentication Service
Distributed set of servers that maintains a database about users.
Each certificate contains the public key of a user and is signed with the private key of a CA.
Is used in S/MIME, IP Security, SSL/TLS and SET.
RSA is recommended to use.

29. X.509 Formats

30. Typical Digital Signature Approach

31. Obtaining a User’s Certificate
Characteristics of certificates generated by CA:
Any user with access to the public key of the CA can recover the user public key that was certified.
No part other than the CA can modify the certificate without this being detected.

34. CA Hierarchy
if both users share a common CA then they are assumed to know its public key
otherwise CA's must form a hierarchy
use certificates linking members of hierarchy to validate other CA's
each CA has certificates for clients (forward) and parent (backward)
each client trusts parents certificates
enable verification of any certificate from one CA by users of all other CAs in hierarchy
If both parties use the same CA, they know its public key and can verify others certificates. If not, then there has to be some means to form a chain of certifications between the CA's used by the two parties, by the use of client and parent certificates. It is assumed that each client trusts its parents certificates.

35. X.509 CA Hierarchy

37. Revocation of Certificates
Reasons for revocation:
The users secret key is assumed to be compromised.
The user is no longer certified by this CA.
The CA’s certificate is assumed to be compromised.

38. Authentication Procedures
X.509 includes three alternative authentication procedures:
One-Way Authentication
Two-Way Authentication
Three-Way Authentication
all use public-key signatures
X.509 also includes three alternative authentication procedures that are intended for use across a variety of applications, used when obtaining and using certificates. 1-way for unidirectional messages (like ), 2-way for interactive sessions when timestamps are used, 3-way for interactive sessions with no need for timestamps (and hence synchronised clocks). See Stallings Figure 14.6 for details of each of these alternatives.

39. One-Way Authentication
1 message ( A->B) used to establish
the identity of A and that message is from A
message was intended for B
integrity & originality of message
message must include timestamp, nonce, B's identity and is signed by A
may include additional info for B
eg session key
One way authentication involves a single transfer of information from one user (A) to another (B), and establishes the details shown above. Note that only the identity of the initiating entity is verified in this process, not that of the responding entity. At a minimum, the message includes a timestamp ,a nonce, and the identity of B and is signed with A’s private key. The message may also include information to be conveyed, such as a session key for B.

40. Two-Way Authentication
2 messages (A->B, B->A) which also establishes in addition:
the identity of B and that reply is from B
that reply is intended for A
integrity & originality of reply
reply includes original nonce from A, also timestamp and nonce from B
may include additional info for A
Two-way authentication thus permits both parties in a communication to verify the identity of the other, thus additionally establishing the above details. The reply message includes the nonce from A, to validate the reply. It also includes a timestamp and nonce generated by B, and possible additional information for A.

41. Three-Way Authentication
3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks
has reply from A back to B containing signed copy of nonce from B
means that timestamps need not be checked or relied upon
Three-Way Authentication includes a final message from A to B, which contains a signed copy of the nonce, so that timestamps need not be checked, for use when synchronized clocks are not available.

42. Authentication Procedures

43. X.509 Version 3
has been recognised that additional information is needed in a certificate
/URL, policy details, usage constraints
rather than explicitly naming new fields defined a general extension method
extensions consist of:
extension identifier
criticality indicator
extension value
The X.509 version 2 format does not convey all of the information that recent design and implementation experience has shown to be needed. Rather than continue to add fields to a fixed format, standards developers felt that a more flexible approach was needed. X.509 version 3 includes a number of optional extensions that may be added to the version 2 format. Each extension consists of an extension identifier, a criticality indicator, and an extension value. The criticality indicator indicates whether an extension can be safely ignored or not (in which case if unknown the certificate is invalid).

44. Certificate Extensions
key and policy information
convey info about subject & issuer keys, plus indicators of certificate policy
certificate subject and issuer attributes
support alternative names, in alternative formats for certificate subject and/or issuer
certificate path constraints
allow constraints on use of certificates by other CA’s
The certificate extensions fall into three main categories:
key and policy information - convey additional information about the subject and issuer keys, plus indicators of certificate policy
subject and issuer attributes - support alternative names, in alternative formats, for a certificate subject or certificate issuer and can convey additional information about the certificate subject
certification path constraints - allow constraint specifications to be included in certificates issued for CA’s by other CA’s

45. Recommended Reading and WEB Sites
(search for kerberos)
Bryant, W. Designing an Authentication System: A Dialogue in Four Scenes.
Kohl, J.; Neuman, B. “The Evolotion of the Kerberos Authentication Service”