11.5 Using Kerberos, RADIUS, and LDAP for WLAN Authentication


11.5 Using Kerberos, RADIUS, and LDAP for WLAN Authentication

While wireless networking applications benefit from location independence and freedom of mobility, they all have the same security challenge ” authentication. When considering a security implementation, authentication is a key component of any security solution. Mutual authentication, where both the client and the server must authenticate with each other, is used to ensure that only authorized users are allowed on the network. Kerberos, Remote Authentication Dial-In User Service (RADIUS), and LDAP are popular and useful authentication solutions that meet this security challenge in WLANs.

Kerberos is designed to enable two parties to exchange private information across an otherwise insecure network. Kerberos provides mutual authentication between a client and a server, as well as between servers, before a network connection can be opened. It uses a technique that involves a shared secret, which works much like a password. This happens by assigning a unique key, called a ticket, to each user who logs on to the network. The ticket is then embedded in messages to identify the sender of the message.

RADIUS servers are robust, scalable servers that provide authentication, authorization, and accounting (AAA) functions and advanced policy and custom configuration management to control user access to wired and wireless networks. Radius and LDAP are often used together in WLAN applications.

The Lightweight Directory Access Protocol (LDAP) is an extensible, vendor-independent network protocol standard, an authentication system, and a directory service that is based on the X.500 Directory Services model. LDAP is an information repository as well as a protocol for querying and manipulating the data in an LDAP directory. LDAP is one of the most widely used authentication directories in modern networks. LDAP is based on the standards contained within the X.500 standard but is much simpler and supports TCP/IP, which is necessary for any type of Internet access. Many of today's WLAN security devices, such as Enterprise Wireless Gate-ways (EWGs), have native LDAP client support.

11.5.1 Kerberos

The Kerberos protocol was first developed by engineers at the Massachusetts Institute of Technology (MIT) in the late 1980s as part of MIT's project Athena [3]. Kerberos is a security system that provides authentication and message protection and is appropriately named after the three-headed dog that guards the entrance of the underworld in Greek mythology. The current version of Kerberos is version 5. Kerberos v5 is RFC 1510 compliant, interoperable with other Kerberos v5 realms that are RFC 1510 compliant, and has some extensions for public key authentication. The primary mechanism for delivering authentication in the Active Directory is the Kerberos protocol. Kerberos v5 is the default authentication protocol for Windows 2000 Active Directory, Windows Server 2003 Active Directory, Windows 2000, and Windows XP clients . Whenever a Windows 2000 or later client authenticates to the Active Directory, the client will always try to use Kerberos. The other protocol that can be used to authenticate to the Active Directory is NTLM, which is supported primarily for backward compatibility with older clients. Kerberos provides both user authentication and encryption key management to guard networks from all forms of attacks on data in transit, including interruption, interception, modification, and fabrication. Kerberos applies a three-pronged security approach: the client, the server, and the trusted intermediary (the Key Distribution Center [KDC]). Kerberos is designed to enable two parties to exchange private information across an otherwise open network.

Kerberos provides the following benefits:

  1. Mutual authentication. The client can verify the server's identity, ensuring that the server that is responding to the client request is the correct server. One server can verify the identity of another. The client can validate its identity to the server.

  2. Trust management. Kerberos trusts are automatically configured and maintained between all of the domains in an Active Directory forest and are transitive and two way. Trusts can also be configured between forests and between Windows Server 2003 Kerberos domains and other Kerberos implementations .

  3. Secure transmission. Messages are encrypted with a variety of encryption keys to ensure that no one can tamper with the client's ticket or with other data in a Kerberos message. Kerberos also prevents the actual password, or any derivation of it, from being sent across the network.

  4. Prevention of replay of authentication packets. Timestamps are used as an authenticator to minimize the risk of someone obtaining and reusing a Kerberos authentication packet. Windows 2000 default clock synchronization requires each packet to be synchronized within 5 minutes of each other. Kerberos authentication will not function if this rule is violated.

  5. Delegated authentication. Delegation refers to a service's ability to impersonate an authenticated user so the user does not need to authenticate to multiple services. Kerberos includes a proxy mechanism that allows a service to impersonate its client when connecting to other services. Delegation is commonly used to effect Internet transactions through intermediary servers. For instance, a client can access e-mail using a browser. In this case, the Web server is delegated the authority of passing the user's credentials to the back-end e-mail server. Kerberos can support delegation because of its unique ticketing mechanism. When sending a ticket to a server, the Kerberos client can add information that the server can reuse to request other tickets on the user's behalf from the Kerberos KDC.

Four components of the Kerberos system allow Kerberos v5 to conduct authentication between the clients and domain controllers in the windows environment. These include the KDC, ticket-granting ticket (TGT), service ticket, and the referral ticket:

  • KDC. The KDC is the network service that supplies both TGTs and service tickets to users and computers on the network. The authentication and exchange of shared secrets between a user and a server is managed by the KDC. Two services are provided by the KDC: the Authentication Service (AS) [4] and the Ticket-Granting Service (TGS) [5]. This AS issues TGTs for connection to the TGS. The TGS then provides the user with a service ticket for authentication with the target network service. The AS returns a TGT for the TGS, which can be reused until it expires [6].

  • TGT. The TGT is provided to users the first time they authenticate with the KDC and is issued by the AS. Once the user receives the TGT, the user can present it to the TGS to request a service ticket. For security purposes, Windows 2000 will verify that the user account has not been disabled. If it has, the KDC will not issue new service tickets to the user.

  • Service ticket. The service ticket is issued to a user by the TGS in response to the user submitting a TGT. Once the user has a service ticket, the user can present this to a network service in order to authenticate with the service and establish a session. The service ticket is encrypted using the key that is shared between the KDC. This ensures that the target server is authenticated because only the target server can decrypt the session.

  • Referral ticket. The referral ticket is actually a TGT to the domain where the resource is located and is issued any time a user attempts to connect to a target server that is a member of a different domain. The AS and TGS functions are separate within the KDC, permitting the user to use the TGT obtained from an AS in their domain to obtain service tickets from a TGS in other domains through the use of referral tickets. The referral ticket is encrypted using an interdomain key between the initial domain and the target domain that is exchanged as part of the establishment of transitive trust relationships.

Three exchanges are involved when the client initially accesses a server resource:

  1. AS exchange. Used by the KDC to provide a user with a logon session key and a TGT for future service ticket requests . Once the user is successfully authenticated, a TGT that is valid for the local domain is granted. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's logon session without requiring the user to reenter a password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network.

  2. TGS exchange. Used by the KDC to distribute service session keys and service tickets. The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine. The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The service ticket that is returned is encrypted using the master key shared by the KDC and the target server so only the target server can decrypt the service ticket. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server authentication exchange, which is described next .

  3. Client/server authentication exchange. Used by a user when presenting a service ticket to a target service on the network. Once the client user has the client/server service ticket, a session can be established with the server. The server can decrypt the information coming indirectly from the TGS using its own long- term key obtained from the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.

Let's look at a three-staged, high-level, step-by-step process of how Kerberos authentication obtains a network service to get a better understanding of how all this works together:

Obtaining the Kerberos TGT

  1. The username, domain name , TGT request, and preauthenticated data are encrypted with the secret key and sent from the workstation to the KDC server.

  2. The KDC server checks the username, extracts the user's secret key, decrypts the preauthentication data, and checks the timestamp.

  3. A message encrypted with the user's secret key is sent to the workstation from the KDC server. The message includes the session key and the TGT that is encrypted with the KDC's long-term key.

  4. The workstation decrypts the message and caches the session key, and the TGT deletes the secret key.

Acquiring a Kerberos session ticket for a network resource

  1. The username, network service name, TGT (that is still encrypted with the KDC's long-term key), and the timestamp encrypted with the session key are sent from the workstation to the KDC server.

  2. The KDC server decrypts the TGT with its long-term key, extracts the session key, decrypts the timestamp, and prepares the session ticket for network service. The session key is sent to the workstation.

  3. The session ticket includes a session key for the client that is encrypted with the client session's key. The session key for network service is encrypted with the network service's long-term key.

  4. The workstation receives and caches the session ticket.

Accessing the network service

  1. The session ticket is sent from the workstation to the network service.

  2. The network service decrypts the network service session key, examines the user access token, and if it is acceptable, grants access.

Now, let's see how the same process would work in a wireless environment to request network service, in this case, e-mail service:

Obtaining the Kerberos TGT

  1. The client associates to the AP.

  2. The AP blocks network access.

  3. The client passes authentication credentials to the AP.

Acquiring of a Kerberos session ticket for a network resource

  1. The AP passes user credentials to the KDC.

  2. The client mutually authenticates with the KDC through the AP. Traffic is encrypted.

  3. The client receives a Kerberos ticket/credentials, enabling it to communicate securely with the AP.

  4. The client provides credentials to and mutually authenticates with the AP.

  5. The AP provides unicast and broadcast WEP keys to the trusted client.

  6. The client is allowed unrestricted access to the network.

Accessing the network service

  1. The client sends a TGT request to the TGS service on the KDC.

  2. The KDC grants a TGT to the client encrypted with the client's password hash.

  3. The client sends a TGT to the TGS, requesting a ticket for the e-mail service.

  4. The TGS sends an e-mail service ticket to the client.

A typical Kerberos implementation in a wireless environment includes several key features and benefits [7]:

  1. Encryption-key distribution is dynamic, and the keys can be changed and securely distributed whenever desired. Key lifetimes can be set from minutes to infinity.

  2. Keys are generated at the start of every session and are allocated on a per-client basis. No sharing of keys among clients is allowed. Key generation also works seamlessly with roaming between APs: new keys are generated when a user begins roaming or when a load-balancing operation is performed.

  3. Mutual authentication ensures that rogue APs cannot capture user data, and encryption prevents a wireless node from operating in RF monitor (sometimes called promiscuous) mode and seeing any user data sent in cleartext format.

  4. Kerberos can scale to support very large networks, and the Kerberos server can be located anywhere on the network. Although the details can be complex, the structure of Kerberos is actually quite elegant and designed for general application in a wired or wireless network. Kerberos is particularly well suited to authentication, encryption, and key distribution on a WLAN.

  5. Some vendors have introduced Kerberos-enabled APs where the AP and the KDC establish reciprocal trust at boot-up. Wireless users associating to the AP mutually authenticate with the KDC and the AP to join the network. By using Kerberos, wireless devices and users fall under the enforcement of existing policies and security procedures many large IT departments have already deployed.

Symbol Technologies is a wireless vendor that supports Kerberos on wireless APs. Symbol calls their proprietary Kerberos KDC appliance the Spectrum24 Mobility Server [8]. The Spectrum24 Mobility Server authenticates usernames and passwords and supports dynamic key distribution, issuing a unique key per session per client and a new key at regular time intervals and on every instance of a roam. Symbol allows two methods of AP integration with Kerberos: with the Kerberos Setup Service (KSS) and without the KSS. The KSS is an optional application provided by Symbol that runs on the KDC server. The KSS is used to administer Symbol's authorized Spectrum24 APs in a Kerberos authentication environment. The KSS has two databases. One database stores valid AP information (AP Setup Account) using each AP's MAC address as the primary identifier. The second database (Kerberos Entry Account) stores Kerberos account information for each AP using the SSID as the primary identifier (all APs with the same SSID are grouped together). Kerberos support is available for Symbol's AP-4131 product [9] without the use of the KSS software. Because the Spectrum 24 Mobility Server is inexpensive in comparison with a large Kerberos infrastructure, it enables the deployment of authentication services at WLAN sites without the high costs associated with a centralized solution across a wide area network.

Kerberos addresses the confidentiality and integrity of information using cryptographic keys, encryption processes, and access control to resources. It does not directly address service availability and attacks. Furthermore, because all of the secret keys are privately held and authentication is performed by the Kerberos TGS and the authentication servers, these servers are vulnerable to both physical attacks and attacks from malicious code. Some of the weaknesses and vulnerabilities of Kerberos are as follows :

  • A client's secret key is stored temporarily on the client workstation and can be compromised along with the session keys that are also stored on the client's computer and the Kerberos server [10].

  • Session keys are decrypted and reside on the user's workstation, either in a cache or in a key table. This makes the session key vulnerable to capture.

  • Kerberos is vulnerable to password guessing. Because a client's password is used in the initiation of the Kerberos request for the service protocol, password guessing through dictionary attacks can be used to impersonate a client. The KDC does not know if a dictionary attack is taking place. Kerberos is vulnerable to a dictionary attack because components of some messages are encrypted with the user's permanent secret key (the one derived from the user's current password) that can, in combination with components of other messages, be correctly deciphered if a correct guess at the user's password is applied to them [11].

  • Tickets passed between clients and servers in the Kerberos authentication model include timestamp and lifetime information. This allows Kerberos clients and Kerberized servers to limit the duration of their user's authentication. The specific length of time for which a user's authentication remains valid after an initial ticket is issued is implementation dependent. Replay attacks can be accomplished on Kerberos if the compromised tickets are used within an allotted time window. Kerberos systems typically use a short enough ticket lifetime to prevent brute force and replay attacks. In general, an authentication ticket should have as short a lifetime as is reasonable. Ideally, the authentication ticket's lifetime should be no longer than the expected time required to crack the encryption of the ticket [12].

  • If encryption is not enabled, network traffic is not protected by Kerberos.

  • If a user changes a password, the secret key is also changed, and the KDC database needs to be updated.

  • The KDC can become a single point of failure if it becomes inoperable. In this case, no one would be able to access needed resources, which would result in a DoS condition for the users.

Despite some shortcomings, a Kerberos-based approach to wireless security is an efficient, proven, standards-based implementation that supports user roaming while addressing all of the known security deficiencies in the current 802.11 standard [13]. The 802.11i standard, when approved, is expected to provide an extensible framework, allowing a variety of techniques, including Kerberos, to be included for any specific security solution implemented at a given site [14]. Although Kerberos has exceptionally low overhead, making it well suited for WLAN applications, Kerberos is complex and requires training and experience to implement correctly.

11.5.2 RADIUS

RADIUS is a widely deployed protocol for network access AAA. Although there are many issues with RADIUS, including issues with security and transport, it will more than likely remain widely used for years to come because it is simple, efficient, and easy to implement. A username and password are entered to access the network and are passed by the Network Access Server (NAS) to a RADIUS server, which verifies that the information is correct and validated with its database. Access to the system is then authorized by RADIUS in accordance with rules configured by the network administrator. The AP plays the role of the NAS in a WLAN. RADIUS can use either an internal native database of users or may optionally point to an external (usually LDAP-compliant or -compatible) database such as Active Directory or Novell Directory Services. The transition from hardware authentication (MAC addresses) and shared keys (WEP) to user-based authentication (RADIUS) is one of the most important steps in ensuring scalability as you secure a WLAN. RADIUS is already in use in many organizations for wired networks, making adoption for the wireless segment easier.

RADIUS has been overwhelmingly adopted as the preferred authentication process for WLANs using 802.1 x -based security solutions. Suggestions on RADIUS usage of IEEE 802.1 x authenticators are provided in RFC 3580 [15], which was released in September 2003. There are several advantages to using RADIUS for authentication. RADIUS authentication is not based on hardware, reducing costs and administration overhead when upgrades occur or authentication data is changed. Accounting and auditing features are available in RADIUS, allowing enterprises to audit usage and create alarms for suspected unauthorized intrusion.

RADIUS also works just as well with VPNs in a wireless environment as it does with 802.1 x /EAP-based solutions. The significant differences between the two are that each uses a different NAS device type and authentication protocol. In regard to the NAS device, the RADIUS server only cares about what type of protocol it supports. No matter how good a particular authentication and encryption technique might be, hackers are getting smarter all the time. It is impossible to develop an impenetrable security technology, so the goal of any security philosophy is to make it extremely difficult and unrewarding for unauthorized individuals to obtain access to network resources and information. A Kerberos-based approach to wireless does this with an efficient, proven, standards-based implementation that supports user roaming while addressing all of the known security deficiencies in the current 802.11 standard. The 802.11i standard, when approved, is expected to provide an extensible framework, allowing a variety of techniques. The success of the implementation of RADIUS in a WLAN depends largely on the selection of the server and the feature set to be used. Some of the factors and features that must be considered before implementing RADIUS with a specific security solution at any given site include the following:

  • Accounting

  • Clustering and failover support

  • EAP support

  • Legacy authentication protocol support

  • Multiple RAS vendor support

  • Mutual authentication support

  • Scalability

  • Software/appliance implementations including Kerberos

RADIUS servers should be selected and configured to meet not only the current transaction load, but also projected workload demands. Deploying a bare minimum configuration will raise long-term costs assuming the network load and the user base grow in the future. The baselining data, a site survey, and a review of projected growth curves are tools that should be employed to determine the necessary scalability before deciding on a RADIUS server configuration. Scalability can be determined by the RADIUS server's capability in passing authentication requests to another such server in lieu of proxy authentication. The RADIUS server's native database is the only one used, which becomes a limiting factor.

The RADIUS server should, of necessity, support the type of EAP in place in the organization. The wireless infrastructure devices chosen must support an EAP type matching the one supported by the server if an existing RADIUS server is already in the organization and cannot be changed.

If the RADIUS package selected supports a clustered design, new advantages and disadvantages enter into the equation. Clustering means that multiple servers, at an additional cost, run as a single computer, each sharing in the application's workload. Clearly, the operating systems running on such servers must also support clustering. This might create the need for additional licensing fees, software upgrades, and other ancillary costs; however, the benefits of clustering include built-in failover and redundancy. This protects the organization from data loss, reduces network downtime, and uses every bit of the deployed CPU power most efficiently .

RADIUS accounting permits a RADIUS server to track when users start and stop their dial-in connections and to acquire data about each session. Using RADIUS accounting, the RADIUS server maintains a history of all user dial-in sessions, indicating start time, stop time, and various statistics about the session. It also provides a current user list indicating which users are currently connected to which Remote Access Servers (RAS). The data collected by RADIUS accounting may be easily exported to spreadsheets or databases, where it can be analyzed by security personnel. RADIUS accounting provides ISPs with data for concurrency statistical monitoring (accounting for the number of concurrent logins per user), which can be fed into their billing software; this allows the ISP to charge the clients for additional logins or simultaneous logins. Other types of organizations may find this form of monitoring helpful where a central service provider passes charges through to other divisions in the organization as an internal cost.

The latest RADIUS server software normally provides support for MS-CHAP, MS-CHAPv2, multiple EAP types, and other types of authentication. A RADIUS software package that will support the authentication protocol(s) that are being used by the particular NAS units should be selected when implementing RADIUS. When legacy RAS devices are in place, it may be appropriate to select a less secure authentication but more mature protocol. Initially, it may be best to integrate support for legacy and leading-edge authentication protocols simultaneously to make the transition between older and newer systems easier and more cost effective. This is not an uncommon practice when moving between wireless VPN systems and 802.1 x /EAP-based solutions.

The use of two-way login validation as mutual authentication instead of one-way authentication eliminates the risk of man-in-the-middle and rogue AP attacks. When one-way authentication is used, the client sends authentication credentials to the RADIUS server for verification. In two-way authentication, the server normally identifies itself to the client as a valid authentication server before client authentication. Mutual authentication can also refer to both the client and the AP having to authenticate to the authentication server. Mutual authentication support is an important feature to have as part of a RADIUS package used in wireless systems.

RADIUS protocol support is one particular feature to look for when purchasing a RADIUS server package. There are many types of RADIUS protocols, so the RADIUS server must be configured to speak the proper " dialect " to the local NAS. It is important to ensure that the RADIUS server is going to work with your organization's NAS.

RADIUS servers are available in various forms to include hardware appliances and software packages, and can even be integrated into wireless infrastructure devices such as APs. Most RADIUS appliances are rack-mountable units in a metal 1U chassis, running FreeBSD or Linux with open-source RADIUS applications or, more recently, Windows 2003. RADIUS appliances can provide either a centralized solution for controlling WLAN users or they may act as a RADIUS authentication proxy device. Appliance solutions are appropriate for nearly any size business (in large enterprises where distributed proxy RADIUS devices can help alleviate congested WAN links and in small and medium- sized businesses where a moderately scalable RADIUS solution may be practical and easy to manage).

RADIUS servers integrated into APs can use either internal user databases for authentication lookup or verify user credentials using another vendor's database through proxy authentication. These are stand-alone solutions appropriate for SOHO environments where there are a small number of users and the security solution is designed to minimize costs.

RADIUS server software is available on Windows, Linux, or Unix platforms. The costs for purchasing RADIUS software packages can range from free to very expensive depending on platform support, feature sets, and scalability. Scalability and redundancy are the biggest advantages of software-based RADIUS solutions. After a software RADIUS server package is installed, it is configured with an administrative software tool. In some cases, it is more appropriate to use a small-scale , purpose-built RADIUS implementation rather than a large, centralized RADIUS server (e.g., on a distributed WLAN with many hotspots, such as that offered by an ISP). It is advantageous and more scalable to have inexpensive RADIUS servers located at each site to perform key rotation/distribution, proxy authentication, and other wireless-specific functions locally. These "scaled-down" RADIUS servers would have to implement 802.1 x /EAP in its various formats in order to be used effectively with WLANs.

Thoughtful decision making about how and where to deploy RADIUS servers in wireless environments will go a long way toward building a cost-effective and scalable network; however, some more typical deployment scenarios should be explored before inventing something new. These designs all work well: some are designed for a single site, whereas others are a better fit for a campus environment where secure roaming is desirable; other designs best serve organizations with multiple sites and combinations of architectures. Typical RADIUS configuration scenarios include the following:

  • Centralized authentication

  • Centralized authentication and security

  • Combination architectures

  • Distributed sites and security

  • Distributed sites

  • Distributed autonomous sites

  • Single-site deployments

In a single-site deployment scenario, all WLAN users are located at a single site and a central authentication database handles all user authentications. Authentication of users, management of WLAN and/or remote access, and establishing secure WLAN connections is handled by one or more RADIUS servers. WLAN users can be authenticated against any back-end authentication database that your RADIUS server supports. RADIUS/AAA servers and APs can be added to scale and to authenticate users against the central authentication database. If the spike in user growth is significant, it may make sense to use the distributed scenario because it scales much better than the single-site deployment model.

In the distributed autonomous sites (or networks) scenario, all user authentication happens locally by replicating the authentication database from the central site downstream to each autonomous site or network. WLAN and/or remote access use is available at each autonomous site or network and managed through the use of one or more RADIUS servers. The availability of a central site network or operating hub is not an issue in this scenario. Each RADIUS server handles user authentication locally, sets up secure WLAN connections, and if necessary, records accounting data. In this scenario, access to your network is governed locally and is not subject to the reliability of a link back to a central authentication store. You can easily add RADIUS servers to absorb the performance hit associated with adding new WLAN users. The distributed RADIUS servers handle the full computational load associated with setting up the secure WLAN connection. Although this architecture is appropriate on networks where authentication databases are deployed (which can be easily and reliably replicated, such as Windows or LDAP), it may not be appropriate for authentication systems such as token systems or SQL databases, which are not easily replicated.

In the distributed sites with centralized authentication and security scenario, WLAN APs at each site or on each network authenticate users against an authentication database located at a central site or operating hub in an architecture composed of distributed sites, networks, or clusters of APs. All WLAN and/or remote access use is managed at a central site through one or more RADIUS servers. The central site RADIUS server handles user authentication locally, sets up the user's secure connection, and if necessary, records accounting data. As with the distributed autonomous site scenario, the availability of a central site network or operating hub is an issue. Bandwidth usage may also be an issue. A RADIUS/AAA server is not needed on each satellite location, network, or AP cluster in this scenario, but it presents two issues that merit consideration. Although this scenario carries certain cost benefits, some issues should be considered before selection and deployment. A WLAN user's ability to connect to the network depends on the status of the link between the distributed networks and the central site or operating hub. Users will not be able to connect to the network if this link goes down. If the network does go down, rekeying for security purposes will be required for users who are disconnected from the network. The RADIUS/AAA server at the central site must perform the cryptographic computations necessary to set up the secure WLAN connection in addition to its primary function of authenticating users. A performance bottleneck can result if you are managing a large number of WLAN users. This problem can be alleviated by adding RADIUS servers as your WLAN user population grows. This scenario is appropriate for networks connected by very fast, highly reliable links. It also has advantages when it is not practical to replicate the authentication database to each distributed network, such as environments in which you require WLAN users to authenticate through some type of token.

In both the distributed sites and centralized security scenarios, the authentication database is located at the central site or at a network hub. WLAN and/or remote access usage is located at each site, network, or AP cluster, and authentication services are managed by one or more RADIUS servers in an architecture composed of distributed sites, networks, or clusters of APs. The distributed RADIUS server queries the central site for user authentication, sets up the secure connection itself, and if necessary, records accounting data locally or forwards data to the central site. The availability of a central site network is an issue. As with the previous scenario, you are at the mercy of the reliability of the link between the distributed network and the central site or operating hub; however, this presents an additional benefit in that you can distribute the load associated with setting up the secure WLAN connection to the RADIUS servers located on the distributed networks, resulting in better performance and using less bandwidth on the link between the distributed and central sites. As with the previous scenario, this scenario is appropriate for networks that are connected by very fast, highly reliable links. It also has advantages where it is not practical to replicate the authentication database to each satellite network, such as in an environment requiring your WLAN users to authenticate through some type of token.

The architectural scenarios presented in the previous paragraphs can be mixed and matched on the network. In some cases, you may have a more distributed approach to your WLAN deployment where some of your distributed networks may be small, consisting of only a few WLAN users. You may want to forego installing a RADIUS server if those networks are linked reliably to your central site and have your central site RADIUS server handle their authentication and security. There may be other cases where you have one or two remote offices that are not reliably linked to your central network even though you have deployed a centralized authentication and security scheme. When this occurs, you may have to distribute RADIUS servers to those networks even if only a few WLAN users are in that location, in order to protect the integrity and security of the network. A primary benefit of 802.1 x in these types of situations is its flexibility.

11.5.3 LDAP

LDAP is a directory service based on the X.500 Directory Services model that performs operations management functions, acting as a storehouse of information for applications and as a central part of modern OS services. LDAP is both an information repository and a protocol for querying and manipulating the data in a directory. LDAP binds together system information (distributed across multiple computers) with system services and client applications to make it simpler to access user preferences, application configuration data, and security configuration data, and to locate services on the local network.

LDAP is not designed to hold many hundreds of thousands of entries as are traditional databases. LDAP can be thought of as a hierarchically organized lightweight database. It was designed to contain small records of information in a hierarchical structure. The individual nodes contain attributes and connect to other subtrees, so the structure appears much like the directory of a file system. It is important to remember that LDAP uses very small databases to enable fast access, and it cannot be used as if it were a large commercial database such as Oracle, Sybase, DB/2, or SQL Server. There are currently only a handful of native LDAP servers, including the following:

  • IBM's DS Series LDAP Directory (AIX) [16]

  • Innosoft's Distributed Directory Server (Linux) [17]

  • Netscape Directory Server (Linux) [18]

  • OpenLDAP server (Linux) [19]

  • Sun Microsystems' Directory Services (Solaris) [20]

  • University of Michigan's SLAPD [21]

Although Microsoft's Active Directory also uses LDAP natively, it also extends the protocol. Other directory service systems also support LDAP queries, primarily through the use of proprietary APIs with interfaces for LDAP communications. Some of these include Novell's eDirectory, Microsoft's Active Directory, and Lotus Domino.

Native LDAP clients interact with the directory server for authentication and authorization. Clients authenticate to an LDAP server by attempting a bind operation. A connection is established between the client and server if the bind is successful. The client chooses which authentication method it wants to use and supplies the credentials required by that method during the bind process. The client is bound as an anonymous user, and the credentials are sent if an authentication is not specified. LDAP authorization to directory objects is based on an Access Control List (ACL).

LDAP is used as an application server to retrieve information from a directory such as a list of personnel contact information. LDAP is also used by different applications to retrieve the information they require. A user's query can be matched against an LDAP server through the use of a search engine, pointing to the place where the actual data are located. A DNS server can also structure its records internally in an LDAP hierarchy. LDAP can also be used by one application to exchange data with another or as a gateway between two incompatible applications as an interapplication data exchange interface.

LDAP is used by an operating system to communicate information between its different resources or components. The LDAP service can host information about user accounts and preferences for a group of machines. The LDAP server can contain the access rights of user accounts that are referenced by the login system, the file system, and the application execution environment. For example, during user login authentication, the login authentication service on each system is directed to query the LDAP server each time a user attempts to log in. The authentication service checks the results of the query to validate the user. If the user is authorized, it then locates and loads his or her home directory and other personal preferences.

LDAP provides a handful of common APIs to provide services such as user authentication, network host information, network file system locators, and other common network database applications. LDAP provides a basic service for locating information and can be used to store information for other system services, such as RADIUS and Kerberos.

LDAP communications consist of two elements: client-to-server communications and server-to-server communications. Client-to-server communications allow user applications to contact an LDAP server to create, retrieve, modify, and delete data with the standard LDAP commands. The basic command set of LDAP is enough to provide all that client applications should need. The extended command operation in LDAP version 3 provides the capability to add more operations; some vendors may take advantage of LDAP version 3 to create proprietary extended operations to support their product line. Server-to-server communications define how multiple servers on a network share the contents of an LDAP directory information tree and how they update and replicate information between themselves .

The basic LDAP architecture is a simple hierarchical structure of information. At the root node, it provides a hierarchical view of all its data and provides the capability to search the system for this data. The type of data stored can vary depending on how you are using the LDAP server. You may have a set of LDAP servers focused solely on servicing login information requests for the users who are being supported, or you may have a server that contains host address information used by the DNS and DHCP servers. If you do not have a large network, this information could be combined into a single hierarchy, which is called the Directory Information Tree (DIT). Subtrees of the DIT contain all of the information contained on that LDAP server. Each node in the tree is called a Directory Service Entry (DSE). These entries contain the actual records that describe different real and abstract objects in the network infrastructure, such as users, preferences, and devices. Each entry contains a set of properties, or attributes, in which data values are stored. If the real contents already exist somewhere in the directory, then entries can be aliased. A special entry called the root DSE contains a description of the whole tree, its layout, and its contents. This isn't the root of the tree itself because the root node is virtual and doesn't really exist, so it can't be directly accessed.

Enterprise Wireless Gateways (EWGs) are an example of many of today's WLAN devices that have native LDAP client software. Because many of today's WLAN infrastructures use LDAP for user-based authentication, it is essential to understand the LDAP directory and how a client device and LDAP client software would interface. RADIUS is commonly used for user authentication in LDAP with wireless infrastructures . To ensure scalability, most RADIUS software packages have support for interfacing with LDAP-compliant or LDAP-compatible directories. This allows a RADIUS server to query a local LDAP database directly for user authentication. This avoids the requirement of manually entering all users into two databases ”a savings of time and money. Similarly, Kerberos services can be integrated with the Active Directory (or LDAP-compatible) user database, making it more seamless and easier to manage than disparate platforms and services.




Wireless Operational Security
Wireless Operational Security
ISBN: 1555583172
EAN: 2147483647
Year: 2004
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net