• No results found

Port-Based Authentication

N/A
N/A
Protected

Academic year: 2021

Share "Port-Based Authentication"

Copied!
32
0
0

Loading.... (view fulltext now)

Full text

(1)

www.css-security.com ● 425.216.0720

Port-Based Authentication

CSS is introducing its port-based authentication offering in order to take advantage of underutilized, highly effective features of

Microsoft Windows and Active Directory. These features enable an enterprise to block all unauthorized IP access, both from inside the firewall and out, on a connection-by-connection basis. This white paper discusses securing network infrastructure using the RADIUS protocol (IAS), Active Directory, Certificate Services, 802.1X

(wireless and wired), Extensible Authentication Protocol (EAP) and VPN.

W

H

IT

E

P

A

P

E

R

(2)

Table of Contents

Introduction ...1 History ...4 IP Threats to a LAN ...5 Solution Overview ...6 Solution Components ...6

Written Acceptable Use Policies ...7

Requiring Authentication for Any IP Based Connection...8

Identity Based Segmentation...9

Technical Details...10 Protocols ...10 RADIUS...10 802.1X...11 EAP ...13 Components ...15 Clients ...15

Wireless Access Points ...16

Switches...17

VPN...18

IAS Server...18

Directory Server ...19

Certificate Authority...19

(3)

Identity Based Segmentation...23

VLAN ID Reuse...24

Multiple Group Membership ...27

(4)

Introduction

History

The nature of early networking protocol and technology development has left today’s computing environment with many challenges. Early networks had very few nodes and often had limited interconnection to other networks. Considering the cost and rarity of computers, it was assumed that all nodes were trusted. Early protocols assumed this type of environment was secure and often had little or no obfuscation of usernames, passwords or other data. Unfortunately many of those protocols are still used today. In a world of inexpensive laptops,

widespread network access and increasingly savvy users, it can no longer be assumed that data crossing a network is confidential or will reach its destination unaltered.

As the number of threats and level of threat awareness has increased, a great deal of focus has been placed on blocking access to networks from the outside, via firewalls and VPN. This focus has left the state of LAN connections and security almost completely forgotten. Networking hardware manufacturers and standards organizations have worked to address LAN security issues, but many organizations still believe that having a “good” firewall means their IP

infrastructure is protected. Often the only LAN security that is used is router ACLs which merely limit exposure based on a physical port location with no regard to what or who is connected. IPSec is being used occasionally, but it is complex, can put a significant load on processors, and may not work well in a heterogeneous environment. IPSec design, implementation and upkeep can be very costly. It can be difficult to make a business case for requiring IPSec for all LAN traffic. Even if most LAN traffic is encrypted and router ACLs are used, a fair amount of data can be gathered from an open port. The value of the data may be minimized, but not entirely removed.

Most of today’s security technologies assume a user or device has unrestricted access to the network medium. Authentication and authorization take place across the medium with no consideration ever being taken to whether the user or device should have ever been allowed access to IP network. This universally granted access allows the user to take part in the realm or domain security model, or to attempt to circumnavigate or disrupt it, with complete anonymity. While server authentication and authorization mechanisms are effective, allowing any network access to an unknown party is an unneeded risk. Imagine if a bank were to not bother locking its doors at night because the vault and safety deposit boxes all have locks on them. The vault may be strong, but is there any reason to

(5)

allow a thief overnight access to analyze it? Would it be prudent to remove an organization’s firewalls because server ACLs are in place?

Many organizations have had policies banning certain types of devices or network access, but have lacked the technical controls to enforce the policy or audit and provide appropriate behavior modification.

Faced with an onslaught of usernames and passwords, users tend to reuse passwords or write them down on sticky notes. This often weakens a system that implements protocols to provide otherwise secure authentication. It is therefore in the best interest of security to tie any new access-control systems to an existing directory service. Tying all network access to a principal’s existing Active

Directory (AD) credentials allows administrators to implement stronger proactive security measures without the burden of maintaining an additional user directory and the problems that go along with adding yet another set of credentials.

IP Threats to a LAN

On a LAN there are many possible threats. In the past, LAN access and security were often thought of only in terms of identity management and ACLs. Hackers were assumed to be stopped at the firewall and only internal users with valid IDs were able to create mischief. In recent times we’ve seen that many threats on the LAN are independent of identity. Worms such as Code Red and MSBlast

exploited weakness in IP stacks and had no tie to identity; the only requisite for them to wreak their havoc was IP access.

Often the threats come from visitors such as consultants, contractors and vendors. An environment that has strong change control and configuration processes can still be negatively affected by these unmanaged hosts. This can come in the form of a virus infected machine looking for other hosts to infect as well as nosey or curious guests. These threats occur completely outside the realm of a standard domain or realm’s server security model.

Another threat to a LAN comes from employees installing unauthorized workstations and network gear. Unpatched machines with no anti-virus and rogue access points are often found on networks despite what written policy dictates.

Clearly it is in a company’s best interest to block any unauthorized access to its IP infrastructure, whether it originates on a LAN, WAN, wireless or from the internet. The most efficient way to achieve this is by enforcing polices with

technical controls on an automatic port-by-port basis. Managing ports manually is too time consuming and ultimately gets lost in day to day business. Designing a

(6)

system that has little or no long-term administrative overhead is key to having the system work in the real world.

Solution Overview

Port based authentication is the process of blocking traffic through network ports until the identity of the principal requesting access has been established.

Whether it is a physical port such as an RJ-45 connection on a switch or a logical port such as an 802.11 or VPN port, each individual port can be authenticated. Using IAS (Internet Authorization Service), Microsoft’s implementation of RADIUS (Remote Authentication Dial-In User Service), we can tie a principal’s Active Directory credentials to the principal’s ability to connect to the LAN, VPN, wireless, or dial-in. IAS gives us the capability to grant or deny access to network ports based on defined rule sets known as Remote Access Policy.

Internet Authorization Service ships with all Microsoft Server platforms, as do the client pieces for authenticating wired, wireless, dial-in and VPN connections on Windows 2000 XP and 2003 Server. Many existing switches, wireless access points and VPN solutions already support port-based authentication. These factors make port-based authentication a low-cost, high-value proposition.

Solution Components

Understanding the components involved is key to understanding how port-based authentication works. Some of the components have different names depending on context.

(7)

Written Acceptable Use Policies

While the hardware and software components in a system may seem compelling or interesting to administrators, the driving force behind adoption should be the business case. Port-based authentication can be used to technically enforce a documented set of policies. This will help guide designers and administrators in understanding the business needs of those who use the network systems. An Acceptable Use Policy (AUP) is not likely to have a great deal of technical depth, but it can provide a base to build upon. Losing sight of the business case, which is stronger security at a minimal cost, is likely to cause disruptions.

Client

The client machine is often referred to as the supplicant or supplicant port access entity (PAE). The client device requests access to the network, either in the security context of the AD machine account or the user account. The client may access the network via a wireless network interface card (NIC), wired NIC, VPN adapter or modem. Depending on the access type, the client may require third party software to create the connection. This may be third party VPN software or 802.1X supplicant software. Windows 2000 and XP systems come with native VPN and 802.1X capabilities. 802.1X is the IEEE standard that allows for port-based authentication for switches and Wireless APs.

Network Access Server

A network access server (NAS) is a device that allows the client to access the network. It is often referred to as the authenticator PAE or RADIUS client. The NAS can be a switch, access point, VPN concentrator, dial-in device, etc. The RADIUS client has no say in granting or denying access to the network, it merely passes authentication data to the authentication server and enforces the access decision returned to it. The access decision may be as simple as “allow all

access” or it may include restrictions such as date and time, inactivity timeout, IP filtering restrictions, bandwidth restrictions, etc.

Authentication Server

The authentication server, also know as a RADIUS server or IAS server,

determines which clients are granted access to the network. The remote access policy is housed by the IAS server. The IAS server checks AD to validate the identity of the principal, then parses remote-access policy to determine whether or not the connection should be authorized. Once this determination is made, it sends a message to the NAS rejecting or accepting the connection request. Directory Server

(8)

The directory server can be any Active Directory Global Catalog server. The selection of which GC server to use is determined automatically. By default it is the nearest GC server. A directory server is always checked to verify the identity of the user or computer requesting access, as well as to verify that the account is active and that the account is a member of any necessary groups. Often the Authentication server and Directory server will reside on the same box in order to limit the amount of authentication traffic crossing the network.

Certificate Authority

The certificate authority is used to issue and validate server, computer and user certificates. Depending on the scope of the installation, the use of certificates can be minimized or eliminated. If IAS is being used to authenticate wireless

connections, it is required that the IAS server have a certificate in order to protect the authentication process. The IAS server’s certificate can also be used to validate the server, allowing for mutual authentication, which is highly recommended in a wireless environment.

Remote Access Policy

Remote access policy allows for granular, rules-based control over the

authorization process. Once identity is established via Active Directory and/or PKI, remote-access policy is applied to determine whether the connection should be authorized. A NAS (Network Access Server) is a device—such as a VPN concentrator, switch, etc,—that can be used to allow network access. The remote-access policy can take into account NAS MAC address, connecting device MAC address, Time/Day, Group membership, Media type and more. If all policy conditions are met, then the appropriate policy will be applied. The policy can be as simple as granting access to the port or it can return configuration values to assign the connection to a specific VLAN, IP filter set, throttled connection speed, etc.

Requiring Authentication for Any IP Based Connection

Using a single unified remote-access policy,an enterprise can manage all access to its IP infrastructure (Figure 2). This can allow for conditional access by type, such as VPN, dial-in, wireless or wired. It can allow for connections based on location, such as wireless APs only on certain floors, assuming there has been proper documentation of NAS locations. Building-perimeter AP’s can be locked down during non-business hours to further limit parking-lot sniffers. VPN access can be granted only when a valid certificate is used. The flexibility of remote-access policy allows for a high degree of control over how IP is remote-accessed.

(9)

Figure 2 Controlling all IP access via a single Remote-Access Policy

Even if an enterprise is unable to integrate all of its IP access with remote-access policy, it can still benefit from controlling specific types of access. While most third-party VPN concentrator vendors support RADIUS authentication, some of their advanced features may not be supported when using RADIUS. Each piece of hardware has to be reviewed on a case-by-case basis.

Identity Based Segmentation

Very restrictive router ACLs have always looked good on paper but have proved unrealistic in an ever-changing real-world environment. With proper design, identity-based segmentation can greatly restrict IP access with no long term overhead. In an environment that is rapidly changing, it is likely to save a tremendous amount of time in re-design and re-configuration.

Using dynamic VLAN assignment, the possibility arises to begin segmenting a network not based on the physical location of a principal, but based on its

identity. In the past, router ACLs had to be calculated based on who was likely to use an area or might have been used to block access for a legitimate purpose. In addition, if groups moved areas in a facility, the ACLs had to be adjusted or the VLANs moved to different ports or switches. In the end, it is often most expedient to have minimal router ACLs. Now that a principal’s identity can determine which VLAN it is connected to, there is the opportunity to implement extremely tight ACLs.

(10)

In the past a principal’s identity has been used mainly by server administrators to determine access to files, shares, web resources and the like. Now IP

infrastructure designers and implementers can further reduce exposure to IP related incidents.

One of the best examples of the use of this solution is in conference rooms. Even if a network has fairly tight ACLs, a conference room provides two challenges. First, it’s the most likely place to find guests, so access should be tightly limited. Second, there can be a wide range of legitimate users booking the conference room, thus access needs to be fairly broad. These two goals are mutually exclusive. This illustrates why router ACLs are often unutilized or under utilized. With the ability to dynamically assign each port to a different VLAN, a salesman, an engineer and a guest can work in a single room with IP access to only the resources that are deemed necessary for each user.

Another benefit of identity-based segmentation is reduced complexity during moves. Tight ACLs are often avoided due to frequent user moves. There is too much room for human error as well as too much time spent to continually

reconfigure switches for moves. Once an identity-based segmentation model has been implemented, moves have no effect on router ACLs or individual port

configurations.

Technical Details

Protocols

RADIUS

Remote Authentication Dial-In User Service is an Authentication, Authorization and Accounting (AAA) protocol used by network access devices. It creates a framework for allowing or blocking access to network assets as well as shaping the connection and tracking its usage. When a connection is requested to or through a Network Access Server (NAS) the NAS formats the request and passes it to the RADIUS server. The NAS is also known as the RADIUS client. The RADIUS protocol contains a large list of standard RADIUS attributes. These attributes are passed between the client and server to set up, tear down and monitor the connections that are granted to the NAS. The attributes can come from the client describing the nature of the NAS or the peer requesting the

connection, such as the NAS type, NAS IP address, calling station Address, type of connection requested etc. These attributes may also be passed to the NAS to specify connection parameters such as idle timeout, maximum session length, IP filters, etc. The RADIUS protocol is extensible, allowing for custom attributes to

(11)

be created by vendors to support additional features on their NASs. These Vendor-Specific Attributes (VSA) are easily entered into IAS. Not every standard RADIUS attribute is supported by every NAS, so it is important to review the NAS documentation before assuming that an attribute that is being passed will be applied or processed. A NAS will generally ignore any attributes that it doesn’t understand.

The RADIUS client and RADIUS server communicate using a pre-defined shared secret key. The RADIUS protocol, like most shared secret protocols, is subject to offline attacks. It is a best practice to use long randomly generated keys, 16 or more characters. Each RADIUS client is configured separately in the server, so each should have a different key. In addition, whenever possible the RADIUS traffic should be protected by IPSec ESP or other encryption.

802.1X

RADIUS authentication has been around for many years and is generally understood in the realm of VPN and dial-in access. 802.1X was created to expand the RADIUS-like controls to the switch level. While 802.1X development has been driven by the need for wireless security, it is a misconception that 802.1X is a wireless protocol. 802.1X is a protocol that is defined inside layers 1 and 2 of the OSI model. It works on wired connections as well as wireless. While the solutions herein document the use of RADIUS, 802.1X does not require RADIUS. Standalone 802.1X devices are rare and, without a centralized directory to authenticate against, are of limited value in the enterprise.

802.1X initially places all ports in an unauthorized state. In its unauthorized state the only traffic that the port will accept is EAPOL (Extensible Authentication Protocol Over LAN). This is authentication traffic. The only authentication protocol supported in 802.1X is EAP.

There are two separate conversations that take place during authentication. The first part of the conversation is between the supplicant and the authenticator. This conversation takes place at layer 2; therefore no IP addressing is involved. The second part of the conversation is between the authenticator and the

authentication server. This conversation is RADIUS traffic which maps to layer 5. The RADIUS protocol uses UDP datagrams. The RADIUS exchange is protected by a shared secret key. The RADIUS client (authenticator) and the RADIUS server must be configured with each other’s IP addresses and have the same key in order for authentication to be processed. These are import security

designs. The authenticator creates a logical connection from the supplicant to the authentication server to complete the authentication process, but the supplicant has no control over where the authenticator (NAS) sends the authentication data.

(12)

This is determined by the setup of the NAS. This negates the possibility of the supplicant creating a tunnel to some other location.

While 802.1X data is passed by the RADIUS protocol, there are different

terminologies for the same devices. This can be confusing when describing the overall connection process. See Figure 1 and Table 1 for a comparison of the terms.

Table 1 Terminology Cross Reference

Device 802.1X and EAP RADIUS

Supplicant PAE User

Peer

Authenticator PAE RADIUS Client NAS

Authentication Server RADIUS server

Figure 3 illustrates a successful 802.1X authentication. All of the EAP traffic on the left half corresponds with the RADIUS traffic on the right. We see that the layer 2 EAP Response/Identity is packaged by the authenticator into a layer 5 RADIUS-Access-Request and sent to the authentication server (IAS). Then we see the RADIUS-Access-Challenge is returned to the authenticator where it is changed to an EAP-Request-Challenge and sent to the supplicant. The

conversions done by the authenticator make the connection between the supplicant and authentication server logical. There is no “open port” to the authentication server. A better description would be that there is a RADIUS tunnel to the authentication server.

The port remains in the locked (unauthorized) state until the Authenticator

receives the RADIUS-Access-Accept. At that point the port is authorized and all traffic is allowed to pass.

(13)

Figure 3 802.1X Authentication Process

If the authentication server had returned a RADIUS-Access-Reject, the port would have remained in the unauthorized state and been prepared for the next authentication attempt.

The authenticator doesn’t need to know the specifics of the EAP traffic that it is passing, such as the authentication type being used, etc. The authenticator just needs to properly format and forward the EAP traffic to the authentication server. The responsibility of interpreting the EAP traffic and making decisions on whether to grant access lies with the authentication server and the directory server.

EAP

Extensible Authentication Protocol was originally designed to extend

authentication methods for PPP connections such as dial-up, but has since been adapted to frame-based connections as well. EAP provides a framework for passing additional types of authentication through a NAS to the RADIUS server without the NAS having to support each individual type of authentication. With the addition of two RADIUS attributes, EAP-Message and

Message-Authenticator, the NAS and RADIUS servers are able to pass authorization data. There is no standardized framework defined for how a RADIUS server passes and processes the authorization data to the directory server and/or certificate authority. This is left up to the RADIUS implementer. Microsoft integrates the IAS with Active Directory in order to achieve this.

(14)

IAS currently supports three EAP types, EAP-MD5, EAP-TLS and PEAP. The first type, EAP-MD5 is not supported in a wireless environment because it uses a challenge/response mechanism based on an MD5 hash of the principal’s

password. This exchange is subject to offline attack. If the password were short or found on a word list, it would be easily compromised. EAP-TLS uses

certificates to identify the user. This is the strongest form of authentication.

Protected EAP (PEAP) uses a TLS tunnel based on the IAS server’s certificate to protect authentication either using MS-CHAP v2 or EAP-TLS.

Other EAP types exist that are not supported natively by IAS. EAP-TTLS uses a TLS tunnel to pass a variety of supported credentials. While PEAP using TLS seems similar to EAP-TTLS, they are not the same. Tunneled Transport Layer Security (EAP-TTLS) is a proprietary protocol which was developed by Funk Software and Certicom, and is supported by Agere Systems, Proxim, and Avaya. EAP-TTLS is not natively supported by Windows client OSs. LEAP (Lightweight Extensible Authentication Protocol) is a proprietary protocol which was

developed by Cisco and has very little third party support. LEAP should be avoided wherever possible as it is fundamentally flawed and can expose the principal’s credentials during the authentication process. Cisco has given an end-of-life notice on LEAP and is moving to use PEAP. EAP-FAST (Flexible

Authentication via Secure Tunneling) was created as a stop gap solution while transitioning from the flawed LEAP to PEAP. FAST is yet another protocol that uses a secure tunnel to pass credentials. With FAST, the credentials are

username/password. The tunnel can be created using a pre-shared key or using a Diffie-Hellman key agreement.

Table 2 Comparison of IAS Supported EAP types

Feature EAP-MD5 PEAP EAP-TLS

Mutual

Authentication No Yes Yes

Rotating keys for Wireless

(Rekeying)

Not allowed for wireless Generated during authentication Generated during authentication Security technology level Strong password-based authentication Strongest

password-based authentication Strongest authentication

User credential Hash sent in clear (subject to dictionary

Protected by Transport

(15)

protection and brute-force attacks) tunnel authentication

Ease of

implementation

Widely supported and offered natively in Windows clients. Not supported for wireless.

Widely supported and offered natively in Windows clients (2000 and XP).

Requires a Public Key Infrastructure (PKI). Widely supported and offered natively in Windows clients (2000 and XP). Credentials flexibility Username/password only

Any approved EAP in TLS tunnel, including EAP - MSCHAPv2 based passwords

Only digital certificates

Components

Clients

The type of device connecting to the IP infrastructure can greatly influence design. Clients may be servers, workstations, or IP devices such as printers or cameras. The device’s available authentication type may depend on OS, drivers or firmware.

The type of connection is also important. VPN authentication options are highly dependent on the VPN solution being used. Microsoft’s Routing and Remote Access (RRAS) supports all of IAS’s authentication types. Many third-party VPN solutions and dial-in solutions may only support MS-CHAP v2 or weaker. The level of risk must be evaluated for weaker auth types. Dial-in connections, for instance, are a point-to-point connection. If the dial-in NAS is managed internally, passing credentials in the clear is not likely to be a risk. On the other hand, if the NAS is outsourced, it may be necessary to evaluate how the outsourcer handles and logs connection information.

When using 802.1X with switches, some devices such as networked printers may not have supplicant software. If this is the case, the ports for these types of

devices will need to be configured with 802.1X turned off and tightly limited ACLs applied. It is also advised not to use DHCP on these VLANs. By turning off DHCP, the usefulness of the port is limited to the average user. In addition, use of static IP addresses will allow for tighter ACLs.

Windows 2000 and XP natively support 802.1X authentication, PPTP and L2TP. If 802.1X is used by Windows 2000 or XP for wireless connections, the

(16)

supplicant will not allow a connection to be created that does not include encryption. The supported encryption types vary widely by equipment vendor. Windows 2000 and XP also support two different connection security contexts. When the computer first boots, it will attempt to authenticate in the context of the machine account. If the machine account has not been added to an appropriate Windows group, one that matches a remote access policy, then the computer will not be granted access to the IP network. This means that machine group policy will not be refreshed and the machine will not be available to be managed by systems such as SMS. If the machine account is granted access by remote access policy then it will be granted access and available for remote

management, etc. When a user logs onto the machine, the context of the connection is switched to the user’s security context. The user’s context may cause the connection to be closed, reopened in the user’s context or assigned to a different VLAN.

Wireless Access Points

In the realm of wireless access, authentication is not the only concern. The confidentiality of the data also becomes of concern. While many APs support 802.1X authentication only, this is not an acceptable level of security unless the radio frequency (RF) environment is adequate to contain all data being

transmitted wirelessly and local users can all be trusted not to eavesdrop on each other’s data as it crosses the airwaves. This is highly unlikely. RADIUS has additional attributes that can pass dynamic keys to APs after access has been granted. It is vital that these techniques be used. By using dynamic keying, the possibility of a properly authenticated session being hijacked is eliminated. Hijacking an unencrypted session is a fairly simple process, but by also requiring the correct key, it is nearly impossible.

Until recently, most APs that used 802.1X did not support dynamic VLAN

assignment, but recently many vendors have begun selling APs with this option. These APs are often referred to as wireless switches. Wireless switches are vital for creating a guest-friendly wireless network that is still highly secure.

Access point selection is the most critical decision that is made during a wireless rollout. While all current and proposed enterprise authentication mechanisms are based on 802.1X, not all APs and wireless clients support the plethora of

encryption types and key distribution methods. It is important to select the strongest possible security that will work in a given environment. Currently

Wireless Protected Access (WPA) using Advanced Encryption Standard (AES) is the most secure widely used standard, however few currently installed APs support it and even fewer installed wireless client adapters support WPA-AES. WPA-TKIP is much more widely supported in APs and is supported natively in

(17)

Windows XP. However, Windows 2000 requires a third-party client or driver to support WPA-TKIP. WPA2 and 802.1i compatible security protocol is poised to take off, but in the ever changing technology world, is not likely to last forever. An AP that supports WPA, and whose firmware can be flashed to support upcoming changes, is a good long-term choice.

The scores of other important factors that shape buying decisions for a wireless deployment are outside the scope of this document.

Switches

Nearly all of the managed switches sold today, as well as those sold recently, support 802.1X authentication. Some older gear may require firmware upgrades to support 802.1X. When planning for the use of 802.1X compliant switches, there are a few key factors to take into account. First is whether or not the environment can or will support dynamic VLAN assignment. The second is whether the guest VLAN option is supported. Lastly, if guest VLANs are supported, in what fashion do they operate.

Guest VLAN assignment is not part of the 802.1X standard, so it is handled differently by different manufacturers. Some OSs, such as Windows 2000 and XP, support a guest logon feature using the domain guest account. The Windows solution bypasses the need for the switch to support a guest VLAN by attempting to authenticate the connection as the domain guest user if initial authentication fails. This solution still requires the switch to support dynamic VLAN assignment. The guest VLAN is accomplished by simply having a remote access policy that grants access to the guest user, but on a different VLAN. This, however, doesn’t address the needs of non-MS clients. Networking gear that natively supports a guest VLAN can work in one of two ways. The first type assigns the connection to a guest VLAN only if no 802.1X authentication is attempted. This is based on the assumption that the device connecting has no available supplicant software. The second type works like the MS solution, granting access to the guest VLAN if authentication fails. Some gear only supports one option, some gear supports both. It is most useful to have hardware support for clients that attempt no 802.1X authentication. This reduces the number of ports that must have 802.1X completely turned off.

By operating at the Link Layer, 802.1X tightly controls access to and through wired ports. The enabled 802.1X port always starts in the unauthorized state. In the unauthorized state the port ignores all traffic except for EAP Over LAN (EAPOL). As soon as a device is connected to the port, it initiates authentication by sending an EAP-Request/Identity. If the authentication process completes successfully, the port is changed to the authorized state and all traffic is allowed to pass. If, for any reason, the physical connection is lost, the port immediately

(18)

returns to the unauthorized state. This mechanism makes it nearly impossible to hijack an authorized port. Some vendors can also support authenticating more than one MAC address per port, which allows for expansion using a hub while maintaining most of the integrity of the connection. The switch port has no mechanism to track the link state of the client’s connection to the hub, so use of this type of option should be avoided in an environment that isn’t considered physically secure.

VPN

Microsoft’s RRAS is tightly integrated with IAS. RRAS can receive additional connection parameters from IAS beyond what standard RADIUS attributes would allow for. This can include required encryption type and IP filters. This allows for granular configuration of the user’s connection based on remote access policy. Each third party VPN solution has a different set of standard and vendor specific RADIUS attributes that it can interpret and act on.

Most third party VPN products will support EAP-TLS authentication, which is recommended for allowing VPN access. Administrative accounts should require two factor authentication such as is provided by smart cards.

IAS Server

Internet Authentication Service ships with the Windows 2000 and 2003 operating systems; however Windows 2003 Enterprise Edition has some advantages over the other OSs. In particular, Windows 2003 Enterprise supports unlimited

RADIUS clients, whereas Windows 2003 Standard supports up to 50. Windows 2003 Enterprise supports creating RADIUS clients using a block of IP address, while Windows 2003 Standard requires that each RADIUS client be added separately. Windows 2003 also gives greater control over the specifics of EAP auth types. With Windows 2000, if auth type was selected, it was universally accepted. Windows 2003 IAS allows for remote access policy to have more granular control. Now a policy can specify the particular certificate that must be used or the Certificate Authority that must have issued the certificate. In addition, Windows 2003 IAS can parse a certificate’s Enhanced Key Usage (EKU)

properties to enforce the certificate’s intended use. Some vendors ignore EKU information and use any certificate for which the principal has a private key. This can also be used to enforce stronger authentication methods, such as smart cards for administrative accounts, VPN, etc.

IAS supports NASs that are compliant with RADIUS RFCs 2865 and 2866 and computers running MS RRAS. This standards-based support is what makes IAS a strong choice for integrating IP access with an existing directory.

(19)

Each IAS server is assigned to the RAS/IAS Server Group of its domain. This allows the IAS server to read each principal’s account attributes to determine account status and group membership. If an IAS server must authenticate users from another domain, it must be placed in that domain’s RAS/IAS Server group. Directory Server

Microsoft’s Active Directory (AD) is the framework for the required directory services. All access requests are checked against Active Directory in order to ascertain a principal’s group memberships, account status and other relevant information. Due to IAS’s constant communication with AD, it is recommended that IAS be run on a directory server. This will greatly reduce the amount of authentication traffic crossing the network.

Certificate Authority

Depending on the scope of the installation, a full Public Key Infrastructure (PKI) is not needed. Certificates are required on the IAS server for wireless

connections and any connection that requires mutual authentication. For wireless connections, it is imperative that the authentication process be protected and that the client be able to verify the identity of the system to which it is authenticating. This can only be accomplished with public key technology.

To best leverage PKI, it is recommended that certificate auto-enrollment be used. Windows 2000 supported auto-enrollment only for machine certificates, but

Windows 2003 introduced user-certificate auto-enrollment. This, however, only works when used with Windows XP clients. Auto-enrollment allows for both certificate enrollment and certificate renewal.

Requiring principals to present a certificate in order to connect to the network ensures that users don’t share usernames and passwords. By default Windows 2000 and XP used cached user credentials to attempt 802.1X authentication, but the supplicant can be configured to use an alternate username and password. By default MS VPN connections ask for credentials, which could be shared.

Requiring certificates and properly securing the provisioning process increases the strength of the authentication and eliminates the opportunity to share passwords.

Remote Access Policy Processing

Remote Access Policy is an ordered list of policies that are checked to see if a connection will be granted and, if so, determine the connection attributes to be returned to the NAS.

(20)

Figure 4 Remote Access Policy List example

Each individual Remote Access Policy contains a list of Policy Conditions. When a connection request is made, it is compared to the first Remote Access Policy on the list. Only if all of the policy conditions are met is the Remote Access Policy applied to the connection. If any of the policy conditions are not met, the

connection request is processed against the next Remote Access Policy. Figure 5 Policy Conditions

When the connection request reaches a policy in which all the policy conditions are met, the connection is processed. Processing the connection first means

(21)

verifying that the principal’s account does not have an explicit deny remote access attribute.

At this point IAS checks whether the policy is set to Grant Remote access permission or Deny remote access permission. If the policy is set to deny, the connection request is rejected and no further policies are parsed.

If the policy is set to Grant remote access permission, the policy’s profile is checked. The policy profile is partially redundant with the policy conditions. The profile can specify what type of authentication is used, e.g. EAP, MS-Chap v2 etc. The profile can also require call-back numbers for dial-in and date-time restrictions. In many cases, these conditions are returned to the Network Access Server as RADIUS attributes for later enforcement. This may enforce a session time out or date-time restrictions. This is because the remote access policy is only parsed during authentication. Once access is granted, IAS turns over control of the connection to the NAS. Not all NASs understand all RADIUS attributes, so it is important to read the manual and not assume that any restrictions will be understood and enforced. Figure 4 shows some of the profile restrictions. The IP and encryption tabs only apply to connections that are granted through MS Routing and Remote Access servers. The Multilink tab offers options for binding two modems into a single, faster, dial-in session. The Advanced tab is used to pass additional RADIUS attributes to the NAS when access requests are granted.

Figure 6 Policy Profiles

(22)

If the profile conditions are met, the access request is granted and any specified RADIUS attributes are returned to the NAS. At this point no further remote access policies are parsed.

Windows server 2003 introduced a new principal attribute, Ignore-User-Dialin-Properties. This attribute bypasses the policy’s grant or deny remote access attribute, but still requires that the profile conditions be met. Figure 5 shows the remote access policy processing flow for IAS servers running Windows 2003 server. The flow for Windows 2000 server is the same except that the Ignore-User-Dialin-Properties attribute is ignored.

Remote Access Policy is the heart of port-based authentication. Policies must be closely evaluated both in terms of the order in which they occur and the policy conditions that must be met for the policy to be applied. If the policies near the top are too vague or general, the conditions may be met and policy processing stopped before any desired more-specific policies can be processed. It is best to place complex policies and deny policies near the top of the list. The final policy should have conditions that are universally met and that deny access. Typically the only policy condition would be a date-time condition that covers all times. The profile would have no authentication options selected. This will cause the

connection to be rejected even if the Ignore-User-Dialin-Properties attribute is present.

(23)

Figure 7 Remote Access Policy processing

Identity Based Segmentation

As discussed in the overview, identity-based segmentation allows for a tightly managed IP environment. This is achieved by dynamically assigning a principal’s connection to a specific VLAN based on Remote Access Policy. The policy applied is likely to be based on the principal’s group membership and/or connection location. By always assigning a principal’s connection to a specific VLAN, the router ACLs can be significantly tightened to reduce the principal’s exposure to the IP network and vice versa.

(24)

VLANs are dependent on networking gear that supports 802.1Q tagged frames. In a standard LAN all multicast and broadcast traffic is delivered to each station. In the past the LAN was limited to a single hub, switch or a group of cascaded devices. Using 802.1Q tagged frames and compatible gear, a LAN can now be configured to span devices on a port-by-port basis as opposed to every port on each connected device. For a VLAN to span two or more switches, they must all be connected by interfaces that are 802.1Q compliant.

Deciding how to configure identity-based segmentation depends on several factors. The main factors are the capabilities of the networking gear, the available bandwidth of inter-site network connections, and Windows group membership. VLANs are layer 2 MAC bridges so it may not be prudent to pass this traffic across WAN links. While a principal can be a member of many groups, it can only be assigned to a single VLAN.

With proper planning, identity-based segmentation can significantly improve security without adversely affecting a principal’s ability to use approved network resources.

VLAN ID Reuse

If necessary, VLAN IDs (VIDs) can be reused on systems that are not connected by 802.1Q compliant interfaces. This can help reduce the complexity of remote access policy. In order to keep a VLAN from spanning a WAN link, or if a WAN link can’t support VLAN tagging, the same VID can be used at two locations. The two VLANs, while having the same VID, will not be a single broadcast domain and will thus be completely separate VLANs despite sharing the same VID. In example 1, the desired result is to assign members of three different user groups to a VLAN with the correct ACLs no matter where they physically attach to the network.

Table 3 Identity Based Segmentation Example

Group Assigned VID

Accounting 112

Engineering 117

Marketing 115

The remote access policy to assign the correct VLANs to these user groups might look like Table 4. This policy takes into account the principal’s group

membership, network access types and authentication type with no regard to the principal’s physical location.

(25)

Table 4 Remote Access Policy

Policy Order Policy Conditions RADIUS Attribute returned

conditions if met

1 Windows Group matches Accounting NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS

Assigned-VLAN = 112 2 Windows Group matches Engineering

NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS

Assigned-VLAN = 117 3 Windows Group matches Marketing

NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS

Assigned-VLAN = 115

Figure 8 shows two switches that can pass VLAN tags, thus creating layer 2 broadcast domains that span the switches. The VIDs and the subnets that are associated with them are the same on both switches, allowing for a single set of router ACLs to be assigned. It is not necessary to take into account which port will be assigned to which VLAN on a specific switch.

Figure 8 Dynamically assigned VLANs spanning switches

In Figure 9 the switches have no means of passing VLAN tags. While they use the same VIDs that were assigned in Table 4, the subnets are different on each switch because there are six different VLANs. By using equivalent ACLs for the VLANs that will correspond to the same user groups, the same simple remote access policy as in Figure 8 can be used.

(26)

Figure 9 Reusing dynamically assigned VLAN IDs

If VLAN IDs were not re-used, as in Figure 10, the remote access policy would become much more complex. In figure 10, there are six VIDs and six different subnets. The policy would need to account for the specific switch from which a principal was connecting in addition to group membership and then assign the user to the appropriate VLAN. This additional complexity creates unneeded room for misconfiguration. The router ACLs in figure 10 would be the same as in figure 9, but the remote access policy would double. In Table 5, there are two entries for each Windows group, one for each switch from which a principal might connect.

(27)

Table 5 Added complexity to remote access policy by not reusing VIDs

Policy Order Policy Conditions RADIUS Attribute returned

conditions if met

1 Windows Group matches Accounting NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS NAS-Identifier matches Switch C

Assigned-VLAN = 112

2 Windows Group matches Accounting NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS NAS-Identifier matches Switch D

Assigned-VLAN = 120

3 Windows Group matches Engineering NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS NAS-Identifier matches Switch C

Assigned-VLAN = 117

4 Windows Group matches Engineering NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS NAS-Identifier matches Switch D

Assigned-VLAN = 127

5 Windows Group matches Marketing NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS NAS-Identifier matches Switch C

Assigned-VLAN = 115

6 Windows Group matches Marketing NAS-Port-Type matches Ethernet Auth-Type matches EAP-TLS NAS-Identifier matches Switch D

Assigned-VLAN = 135

In comparing Table 4 to Table 5, it can be seen that by not reusing VLANs remote access policy becomes very complex or at least lengthy. By adding an additional switch, remote access policy becomes a daunting task. By reusing VIDs, the number of policies needed becomes equal to the number of groups. If the VIDs are not reused, the number of remote access policies needed is equal to the number of groups multiplied by the number of switches. If the three user-group scenarios above were located on a small business campus spanning three buildings with three floors per building this would mean 27 policies. (3 groups X 9 switches = 27 policies)

Multiple Group Membership

While a principal will often be a member of several Windows groups, it can only be assigned to one VLAN. This makes proper planning essential. Remote-access

(28)

policy will only apply the first matching policy and then stop processing the connection request. This means a user who is a sales engineer and thus a

member of the Windows groups for Sales and for Engineering might be assigned to a VLAN for either and thus be cut off from resources available only from the other VLAN.

The tighter router ACLs are not meant to replace file share ACLs. They are only meant to reduce exposure to other IP resources. IP network designers should work closely with server administrators to design a solution that allows for tightly controlled access without blocking legitimate access.

While there is no “right” way to define router ACLs when using Identity-based segmentation. An easy way to start is to look at connections in terms of

resources—users. Using a model that only allows a user to access data centers, etc., and no other resources significantly reduces exposure to random-dial viruses and nosey and/or malicious users. It also helps enforce policies guarding against users having file shares on their PCs. There is absolutely no reason for the average user to access a resource on another user subnet. If there is a business process that requires this, it is likely that the process is flawed and the resource that is being offered should be moved to a resource subnet such as a datacenter.

If router ACLs are to be used to limit access to specific servers based on the groups that will use them, it is important to verify which servers belong to specific groups and which may need to be available to all users or cross-functional

(29)

Glossary

802.11i

The most recent IEEE standard governing wireless security. The 802.11i architecture contains the following components: 802.1X for authentication (entailing the use of EAP and an authentication server), RSN for keeping track of associations and CCMP to provide confidentiality, integrity and origin authentication.

802.1Q

The IEEE standard that provides for frame headers that create support VLANs. See VLAN.

802.1X

The IEEE standard that defines the performance of, and minimum standards for, port-based authentication.

Access Control List (ACL)

A list of groups and users that are granted access to a specific resource, such as a file share, print server, or specific IP subnet. The ACL often defines what level of access each principal is granted.

Acceptable Use Policy (AUP)

A written policy defining the types of use allowed for a network or workstation. It also defines consequences for violation of the policy. Extensible Authentication Protocol (EAP)

Provides a general protocol for AAA functions in PPP and related servers. It defines an authentication framework that can be expanded in order to meet specific requirements.

EAP Flexible Authentication via Secure Tunneling (EAP-FAST)

Created by Cisco as a stop-gap solution while transitioning from the flawed LEAP to PEAP. With FAST, the credentials are

username/password. The tunnel can be created using a pre-shared key or using a Diffie-Hellman key agreement.

EAP-MD5

EAP method that verifies user name and password by passing and comparing an MD5 hash of the principals credential. This method is not allowed by IAS for wireless authentication due to the inherent dangers of passing hashed passwords.

(30)

EAP Over LAN (EAPoL)

EAP was original designed for use with PPP connections such as dial-up. EAPoL is a modification used to pass EAP traffic over a LAN. It is an integral part of 802.1X.

EAP Transport Layer Security (EAP-TLS)

EAP using a certificate that allows for client authentication to create a TLS tunnel to perform authentication of the principal requesting access. See TLS.

EAP Tunneled Transport Layer Security (EAP-TTLS)

Proprietary protocol developed by Funk Software and Certicom. It is supported by Agere Systems, Proxim, and Avaya. EAP-TTLS is not natively supported by Windows client OSs. EAP-TTLS protects the EAP exchange using a TLS tunnel, but is not compatible with EAP-TLS. Internet Authentication Service (IAS)

Microsoft’s implementation of a RADIUS server. It can be integrated with Active Directory to provide for authentication against the user base of a Windows domain.

IP Security (IPSec)

A protocol suite that provides for authentication of endpoints with options for payload encryption and integrity checks.

Lightweight Extensible Authentication Protocol (LEAP)

A proprietary wireless authentication protocol that was developed by Cisco. LEAP is fundamentally flawed and can expose the principal’s credentials during the authentication process. Cisco has given an end-of-life notice on LEAP and is moving to use PEAP.

Network Authentication Server (NAS)

A device such as a switch, access point, dial-in device etc., that allows access to a network. It passes a client’s authentication data to a RADIUS server for validation against remote access policy.

Port Access Entity (PAE)

The logical portion of an 802.1X compliant device that request or grants access to the network.

Protected EAP (PEAP)

(31)

create a tunnel to protect the EAP process. This can be used to protect an MS-CHAP v2 exchange to a TLS exchange.

Remote Authentication Dial-In User Service (RADIUS)

An Authentication, Authorization and Accounting (AAA) protocol for applications such as network access. It provides a common language for authenticating and controlling network access and connection parameters in a heterogeneous environment.

RADIUS Client

A RADIUS compliant device that passes authentication data to the RADIUS server and is the logical attachment point for a network connection. It is also referred to as a NAS.

RADIUS Server

The RADIUS device that communicates with the directory. It processes remote-access policy in order to determine whether access should be granted or denied for each connection request.

Remote Access Policy

An ordered list of conditions that, if met, are used by the RADIUS server to determine whether access should be granted or denied.

Transport Layer Security (TLS)

The successor to SSL. It uses PKI to create a secure tunnel through which data can pass.

VLAN Identifier (VID)

A numerical value contained in an 802.1Q header that identifies the VLAN to which the frame should be delivered.

Virtual Local Area Network (VLAN)

A layer 2 broadcast domain that can be managed on or across multiple switches on a port-by-port basis. It is used to reduce the size of the broadcast domain on a switch or to add additional ports on a separate switch.

Vendor Specific Attributes (VSA)

Non-standard RADIUS attributes that can be passed by a RADIUS server to a NAS in order to configure the connection parameters of a connection that has been granted.

Wireless Protected Access (WPA)

(32)

Pre-Shared Key (PSK) mode or using 802.1X authentication to pass dynamic keys. WPA can use Temporal Key Integrity Protocol or AES for

encryption.

Wired Equivalent Privacy (WEP)

An encryption method designed to offer wireless LANs some measure of security. Data sent between the client (a PC or notebook) and the access point is obfuscated using either a 64-bit or 128-bit key.

Wireless Protected Access 2 (WPA2)

The Wi-Fi Alliance’s branding of the IEEE 802.11i standard. See 802.11i. WPA-AES

WPA that uses the Advanced Encryption Standard block cipher to protect the wireless data.

WPA Temporal Key Integrity Protocol (WPA-TKIP)

Modified version of WEP. It increases the number of IVs used with the RC4 cipher, and WPA provides for per frame rekeying.

Figure

Figure 1 Port Based Authentication Components
Figure 2 Controlling all IP access via a single Remote-Access Policy
Table 1 Terminology Cross Reference
Figure 3  802.1X Authentication Process
+7

References

Related documents

Зокрема, організаційну діяльність підприємства пропонуємо розділити на інноваційний (так як ринок освітлювальноїтехніки характеризується

Work-Life Balance, Family-Friendly Policies and Quality of Work Life Issues: Studying Employers' Perspectives of Working Women in Oman... This journal and its contents may be used

Context-Oriented Programming (COP): An emerging programming model aimed at easing the construction of adaptive applications by providing features to support

From the management point of view, the system handles data encryption (Wireless Encryption Protocol; WEP), authentication by a Remote Authentication Dial-In User Service

Authentication • Registration • Credentials management • Entity authentication Access • Authorization • Access control • Accounting Identity Management Access Management

In this paper, using a MNL model and a multi-level data set, we have shown that the investment location decision with respect to FDI in the CEECs is complex and depends on

As the study’s results reveal, the indirect effect of organiza- tional CSR engagement on work addiction via organizational identification and work meaningfulness is stronger at higher

Charles Borromeo Parish wish all our families a most Blessed Christmas.. May Almighty God bless our families and grant them peace and happiness in the