CompTIA Network+ Certification Study Guide part 46 potx

One of the main benefits is the direct reduction in password fatigue that users experience by hav-ing to logon to and keep track of so many different authentication credentials.. SSO can

party’s hands, it can be used to falsely authenticate and identify someone

as a valid party, forging false communications or using the user’s access to gain permissions to the available resources

Original digital authentication systems shared a secret key across the net-work with the entity with which they wanted to authenticate Applications such as Telnet and FTP are examples of programs that simply transmit the user-name and password in cleartext to the party they are authenticating Another area of concern is POP3 e-mail, which, in its default state, sends the complete username and password information in cleartext, with no protection

The problem with this method of authentication is that anyone who monitors a network can possibly capture a secret key and use it to gain access to the services or to attempt to gain higher privileged access with your stolen authentication information

What methods can be used to provide a stronger defense? As discussed previously, sharing a handshake or secret key does not provide long lasting and secure communication or the secure exchange of authentication infor-mation This has led to more secure methods of protection of authentica-tion mechanisms The following secauthentica-tions examine a number of methods that provide a better and more reliable authentication process

NoTES FroM ThE FIEld …

Cleartext Authentication

Cleartext (nonencrypted) authentication is still widely

used by many people who receive their e-mail through

POP3 By default, POP3 client applications send the

username and password unprotected in cleartext from

the e-mail client to the server There are several ways

of protecting e-mail account passwords, including

con-nection encryption.

Encrypting connections between e-mail clients and

servers is the only way of truly protecting your e-mail

authentication password This prevents anyone from

capturing your password or any e-mail you transfer to

your client SSL is the general method used to encrypt

the connection stream from the e-mail client to a

server.

Authentication POP (APOP) is used to provide

password-only encryption for e-mail authentication It

employs a challenge/response method (defined in RFC 1725) that uses a shared time stamp provided by the authenticating server The time stamp is hashed with the username and the shared secret key through the MD5 algorithm.

There are still some problems with this process The first is that all values are known in advance except the shared secret key Because of this, there is nothing provided to protect against a brute force attack on the shared key Another problem is that this security method attempts to protect a password but does nothing to pre-vent anyone from viewing e-mail as it is downloaded to

an e-mail client.

Some brute-force crackers, including POP, Telnet,

FTP, and HTTP, can be found at

http://packetstormse-curity.nl/Crackers/ and can be used as examples for

this technique.

Two-factor authentication can be implemented with a combination of

some-thing you have (for example, Automatic Teller Machine (ATM) cards) and

something you know (a PIN) To misuse your authentication credentials in a

two-factor authentication scheme, an attacker must acquire both your ATM

card and the PIN number This type of authentication may be implemented

in a simple form such as magnetic strip cards as currently used in many

bank ATMs or more sophisticated token cards (available in the form of key

fobs with constantly changing numbers)

Token technology is a method that can be used in networks and facilities

to authenticate users These tokens are not the access tokens that are

granted during a logon session by the NOS Rather, they are physical devices

used for the randomization of a code that can be used to assure the identity

of the individual or service, which has control of them Tokens provide an

extremely high level of authentication because of the multiple parts they

use to verify the identity of the user Token technology is currently regarded

as more secure than many forms of biometrics This is due to the fact that

impersonation and falsification of the token values is extremely difficult

Token authentication can be provided by way of either hardware- or

software-based tokens Let’s take a look at the multiple pieces that make up

the process for authentication using token technology

To start with, you must have a process to create and track random token

access values To do this, you normally use at least two components They

are as follows:

A hardware device that is coded to generate token values at specific

■

■

intervals

A software or server-based component that tracks and verifies that

■

■

these codes are valid

To use this process, the token code is entered into the server/software

monitoring system during setup of the system This begins a process of

tracking the token values, which must be coordinated A user wishing to be

authenticated visits the machine or resource they wish to access, and enters

a PIN number in place of the usual user logon password They are then

asked for the randomly generated number currently present on their token

When entered, this value is checked against the server/software system’s

calculation of the token value If they are the same, the authentication is

complete and the user can access the machine or resource Some vendors

have also implemented a software component that can be installed on

portable devices, such as handhelds and laptops, which emulate the token

device and are installed locally The authentication process is the same; however, the user enters the token value into the appropriate field in the software, which is compared to the required value If correct, the user may log on and access the resource

Vendors such as RSA Security offer products and solutions such as SecurID to use these functions Others implemented processes that involved the use of One Time Password Technology, which often uses a pregenerated list of secured password combinations that may be used for authentication, with a one-time use of each This provides for a level of randomization, but its basic implementation is not as random as other token methods

Multifactor

Three-factor authentication or commonly known as Multifactor authenti-cation is the process in which we expand on the traditional requirements

that exist in a single-factor authentication like a password To accomplish this, multifactor authentication will use another item for authentication

in addition to or in place of the traditional password The use of similar authentication mechanisms repetitively may not be classified as multifactor authentication A three-factor implementation should use three indepen-dent authentication mechanisms available

The following are four possible types of factors that can be used in a multifactor authentication implementation:

A password or a PIN can be defined as a

■

A token or Smart Card can be defined as a

■

A thumbprint, retina, hand, or other biometrically identifiable item

■

■

can be defined as a something you are factor.

Voice or handwriting analysis can be used as a

■

For example, most password-based single authentication methods use a password In multifactor authentication methods, you might enhance the

“something you know” factor by adding a “something you have” factor or a

“something you are” factor

A Smart Card or token device can be a “something you have” factor Mul-tifactor authentication can be extended, if desired, to include such things

as handwriting recognition or voice recognition The benefit of multifactor authentication is that it requires more steps for the process to occur, thus adding another checkpoint to the process, and therefore stronger security For instance, when withdrawing money from the bank with a debit card (“some-thing you have”), you also have to have the PIN number (“some(“some-thing you know”) This can be a disadvantage if the number of steps required to achieve

authentication becomes onerous to the users and they no longer use the

pro-cess or they attempt to bypass the nepro-cessary steps for authentication

To summarize, multifactor authentication is more secure than other

methods because it adds steps that increase the layers of security However,

this must be balanced against the degree to which it inconveniences the

user because this may lead to improper use of the process

Single Sign-On

Single Sign-On (SSO) is a process in which we simplify the access to different

systems by authenticating the user once Many SSO products exist in the

marketplace today and typically SSO implementations will deploy with

stringent policies regarding access control and authorization mechanisms

Group policies can also be used to ensure that simplification does not result

in compromise in security

In a corporate scenario, a user may have to logon to the local

direc-tory services for authentication, a mail service may require another

pass-word, client-server applications such as customer relationship management

(CRM) or enterprise resource planning (ERP) may need authentication and

several other software applications that might have incorporated different

authentication procedures By deploying a SSO solution, the user would be

able to logon a single time and gain access to all these services, instead of

having to retain usernames and passwords for each

There are many benefits from deploying a SSO solution One of the main

benefits is the direct reduction in password fatigue that users experience by

hav-ing to logon to and keep track of so many different authentication credentials

By lessening the burden places on users to retain disparate credentials, there

may be a resulting increase in productivity Simplified management is another

apparent benefit gained when the disparate software systems can work with a

centralized authentication service for a one-time authentication of the users

SSO can be implemented through various NOS including Microsoft

Win-dows 2003 (Internet Authentication Services [IAS]), Microsoft WinWin-dows 2008

(Network Policy Server [NPS]), and Linux systems using Kerberos or through

non-OS implementations such as RSA Enterprise SSO (ESSO) solutions

Authentication Systems

From a simple user authentication to the local domain services to that of

sophisticated online banking system, various authentication systems are

adopted by the organizations As the need for complex security arises,

addi-tional layers of security are added to the rudimentary system of username and

password Operating systems and applications develop vulnerabilities and

hackers come up with innovative methods to circumvent a security design

Introducing a hardware element into the authentication process is some-times considered a higher level of security since an attacker must gain con-trol of both the hardware (such as token card) and exploit the vulnerabilities

of the system to gain unauthorized access

In this section, we’ll discuss about RADIUS, Kerberos, and LDAP authentication services, authentication protocols including PAP, Challenge Handshake Authentication Protocol (CHAP), 802.1x methods and imple-mentations that offer powerful accounting tools such as TACACS+ To begin with, we’ll discuss authentication policies that are used to granularly control the access methods and review the type of authentication protocols that remote users need to comply with to access resources

Remote Access Policies and Authentication

Remote users may connect to the network through dial-in services using a modem and analog line by dialing in to the organization’s modem pool con-nected to a dial-in server or through VPN client software configured on their laptops or remote desktops to connect to the corporate VPN server (often a Firewall with VPN component as in Case of Check Point, Watchguard, Juniper SSG or Cisco ASA appliances or dedicated VPN concentrators) Even wireless clients connecting through the WAPs can be defined as a remote user and restrictions can be applied on them In summary, any user outside the physi-cal LAN can be defined as a remote user and access policies can be applied Authentication servers refer to the directory services before the users are authenticated However, remote access policies go beyond just

authen-ticating the user These policies define how the users can connect to the

network You may also grant or deny the permission to dial-in, based on the credentials presented by the remote users A remote access policy defines the conditions and remote access permissions and creates a profile for every remote connection made to the corporate network

Through remote access policies, you can define the following:

Grant or deny dial-in based on connection parameters such as type

■

■

and time of the day Authentication protocols (PAP, CHAP, EAP, MS-CHAP)

■

■

Validation of the caller ID

■

■

Call back

■

■

Apply connection restrictions upon successful authorization

■

■

Create remote user/connection profile

■

■

Assign a static IP or dynamic IP from the address pool defined for

■

■

remote users

Assign the user to a group to apply group policies

■

■

Configure remote access permission parameters

■

■

Define encryption parameters (for a remote access VPN client)

■

■

Control the duration of the session including maximum time

■

■

allowed and idle time before the connection is reset

Remote Access Policies can be configured in Microsoft Windows 2003

through IAS, in Windows 2008 through NPS, and in Linux variants through

FreeRADIUS

Biometrics

Biometric devices can provide a higher level of authentication than, for

example, a username/password combination However, although they tend

to be relatively secure, they are not impervious to attack For instance, in the

case of fingerprint usage for biometric identification, the device must be able

to interpret the actual presence of the print Early devices that used optical

scans of fingerprints were fooled by fogging device lenses, which provided a

raised impression of the previous user’s print as it highlighted the oils left

by a human finger Some devices are also subject to silicon impressions or

fingerprinting powders that raise the image Current devices may require a

temperature or pulse sense as well as the fingerprint to verify the presence

of the user, or another sensor that is used in conjunction with the print

scanner, such as a scale Biometrics used in conjunction with Smart Cards or

other authentication methods lead to the highest level of security

RADIUS

Users need a centralized entity to handle authentication Initially, RADIUS

was created by Livingston Enterprises to handle dial-in authentication Then

its usage broadened into wireless authentication and VPN authentication

RADIUS is the most popular of all the authentication, authorization, and

accounting (AAA) servers, including TACACS, TACACS+, and DIAMETER

A RAS must be able to authenticate a user, authorize the authenticated user

to perform specified functions, and log (that is, account for) the actions of

users for the duration of the connection

When users dial into a network, RADIUS is used to authenticate

user-names and passwords A RADIUS server can either work alone or in a

distributed environment (known as distributed RADIUS), where RADIUS

servers are configured in a tiered (hierarchical) structure

In a distributed RADIUS environment, a RADIUS server forwards the

authentication request to an enterprise RADIUS server using a protocol

called proxy RADIUS The enterprise RADIUS server handles verification of

user credentials and responds back to the service provider’s RADIUS server One of the reasons that RADIUS is so popular is that it supports a num-ber of protocols including the following:

PPP

■

■

Password Authentication Protocol (PAP)

■

■

CHAP

■

■

Authentication Process

RADIUS authentication consists of five steps (Figure 9.10) as follows:

1 Users initiate a connection with an ISP RAS or corporate RAS

Once a connection is established, users are prompted for a user-name and password

2 The RAS encrypts the username and password using a shared

secret, and passes the encrypted packet to the RADIUS server.

3 The RADIUS server attempts to verify the user’s credentials

against a centralized database

4 If the credentials match those found in the database, the server

responds with an access-accept message If the username does

not exist or the password is incorrect, the server responds with an

access-reject message.

5 The RAS then accepts or rejects the message and grants the

appro-priate rights

rADIus Implementation

Various options are available for the organizations planning to implement RADIUS Some commercial software for enterprises and ISPs, bundled RADIUS appliances, or open source products such as FreeRADIUS

FIGurE 9.10 RADIUS

Authentication Process.

(www.freeradius.org) may be considered for deployment Figure 9.11 shows

a Juniper Networks Steel-Belted RADIUS implementation for server Figure

9.12 shows Odyssey Access Client at the client side

A standard Juniper Networks Steel-Belted RADIUS deployment includes

the following:

Installation of the RADIUS server on a chosen software platform

■

■

(available for SBR EE for Windows XP/2003, Sun Solaris 9/10

[SPARC] and 32-bit versions of Red Hat Enterprise Linux ES 4.0/5)

Configure RADIUS clients (routers, switches, or WAPs) providing the

■

■

RADIUS server details (normally the server IP and a shared secret)

Install Odyssey Access clients on the client laptop (available for

Micro-■

■

soft Windows 2000, Windows XP, and Windows Vista OSs, Microsoft

Windows Mobile 5, Windows Mobile 3, Windows CE 4.2 and CE 5,

and Windows 2003 for Pocket PC, Red Hat Enterprise Linux (RHEL) 3

and 4, and Apple Mac OS X version 10.4x OS

Configure Authentication Protocols and Policies on the RADIUS

■

■

server (Figure 9.11)

Configure authentication parameters on the client side (see Figures 9.12

and 9.13)

FIGurE 9.11 Configur-ing Authentication Policies

on Steel-Belted Radius Server.

Certain “flavors” of RADIUS servers and Web servers can be compromised

by buffer-overflow attacks A buffer-overflow attack occurs when a buffer is

flooded with more information than it can hold The extra data overflows into other buffers and areas of program memory The code injected through

a buffer overflow attack may then be executed by the system and can result

in exploitation of the target system

FIGurE 9.12 Configuring Odyssey Access Clients.

FIGurE 9.13 Configuring Authentication Protocol on an Odyssey Access Client.

hEAd oF ThE ClASS…

Sometimes you Just Get lucky…

Once we lock a door, curiosity leads someone to try

and see what is behind it This is the “cat-and-mouse

game”; that is, network security Many vulnerabilities

found in network security are discovered by hackers

trying to access systems they are not authorized to

use Sometimes, “white-hat” hackers – security

con-sultants hired to test system vulnerabilities – discover

vulnerabilities in their testing Unlike “black-hat” hack-ers, whose intentions are malicious, and “gray-hat” hackers, whose intentions are not malicious, white-hat hackers generally work with companies to fix issues before they become to public knowledge In 2001, RADIUS buffer-overflow attacks were discovered by ISSs while testing the vulnerabilities of the wireless networks.

Kerberos (currently Kerberos v5-1.6.3) is used as the preferred network

authentication protocol in many medium and large environments to

authen-ticate users and services requesting access to resources Kerberos is a

net-work protocol designed to centralize the authentication information for the

user or service requesting the resource This allows authentication of the

entity requesting access (user, machine, service, or process) by the host of

the resource being accessed through the use of secure and encrypted keys

and tickets (authentication tokens) from the authenticating key distribution

center (KDC)

It allows for cross-platform authentication and is available in many

implementations of various NOSs Kerberos is very useful in the

distrib-uted computing environments currently used because it centralizes the

processing of credentials for authentication Kerberos uses timestamping

of its tickets, to help ensure they are not compromised by other entities,

and an overall structure of control that is called a realm Some platforms

use the defined terminology, whereas others such as Windows 2003 or

Windows 2008 use their domain architecture to implement the Kerberos

concepts

Kerberos is described in RFC 1510, which is available on the Web site

www.ietf.org/rfc/rfc1510.txt?number=1510 Developed and owned by the

Massachusetts Institute of Technology (MIT), information about the most

current and previous releases of Kerberos is available on the Web at http://

web.mit.edu/Kerberos

Let’s look at how the Kerberos

process works and how it helps secure

authentication activities in a network

First, let’s look at Figure 9.14, which

shows the default components of a

Kerberos v5 realm:

As can be seen in Figure 9.14, there

is an authentication server requirement

(the KDC) In a Kerberos realm, whether

in a UNIX-based or Windows-based

OS, the authentication process is the

same For this purpose, imagine that a

client needs to access a resource on the

resource server Look at Figure 9.15 as

we proceed, to follow the path for the

authentication, first for logon, then at

Figure 9.16 for the resource access path FIGurE 9.14 Kerberos Required Components.