Authentication Applications Chapter 4 Authentication Applications

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

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

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.

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.

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).

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 (e-mail) packets if unencrypted can be successfully sniffed.

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

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 e-mail

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

Authentication Applications developed to support application-level authentication & digital signatures will discuss Kerberos – a private-key authentication service discuss X.509 - 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.

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

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

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.

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.

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

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

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

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

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]

Overview of Kerberos

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.

Request for Service in Another Realm

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

Kerberos Encryption Techniques

PCBC Mode

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

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.

X.509 Formats

Typical Digital Signature Approach

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.

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.

X.509 CA Hierarchy

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.

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 email), 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.

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.

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.

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.

Authentication Procedures

X.509 Version 3 has been recognised that additional information is needed in a certificate email/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).

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

Recommended Reading and WEB Sites www.whatis.com (search for kerberos) Bryant, W. Designing an Authentication System: A Dialogue in Four Scenes. http://web.mit.edu/kerberos/www/dialogue.html Kohl, J.; Neuman, B. “The Evolotion of the Kerberos Authentication Service” http://web.mit.edu/kerberos/www/papers.html http://www.isi.edu/gost/info/kerberos/