NETW 05A: APPLIED WIRELESS SECURITY Wireless LAN Authentication

1. NETW 05A: APPLIED WIRELESS SECURITY Wireless LAN Authentication By Mohammad Shanehsaz Spring 2005

2. Objectives • Explain the following types of authentication: - Kerberos - EAP / LEAP / PEAP - WEP / TKIP - VPN - Certificates - 2-factor & 3-factor authentication - PAP / CHAP / MS-CHAP-V2 - LDAP / Directory Services - RADIUS / AAA

3. Kerberos • Developed at MIT under project Athena • Provides a trusted third party authentication service for user identification • Provides both user authentication and encryption key management • Uses a ticketing system between clients and servers which is managed by the authentication server

4. Kerberos • The components that make up a Kerberos system are: • The Key Distribution Center • The client & server software components • Kerberos security policies • “Kerberized” applications

5. Key Distribution Center • KDC is a single service running on a server • Provides the Authentication Service and Ticket-Granting Services

6. Authentication Service (AS) • This service issues ticket-granting ticket (TGTs) for connection to the ticket-granting service (TGS) • TGT can be reused until it expires

7. Ticket–Granting Service (TGS) • This service issues tickets for connection to services running on server computers • If clients want access to a service located on another computer, it must request TGT from the authentication service, present it to TGS and ask for a ticket to the computer • See Figure 16.1 on page 384 for this process

10. Kerberos • Supported by Microsoft Win2K and 2003 Windows Server platforms (KDC service is started automatically by the domain controller’s Local Security Authority(LSA) ) • Symbol calls their proprietary KDC appliance the Spectrum24 Mobility Server

11. The basic principles of Kerberos operation • The Key Distribution Center (KDC) knows the secret keys of all clients and servers on the network • The KDC initially exchanges information with the client and server by using secret keys • Kerberos authenticates a client to requested service on a server through TGS, and by issuing temporary symmetric session keys for communications between the client and KDC, the server and KDC, and the client and server • Communication then takes place between the client and the server using those temporary session keys

12. Client to TGS server: Initial Exchange • User enters an ID and password on the client workstation • The client temporary generates the client’s secret key from the password using a one-way hash function • The client sends a request for authentication to the TGS server using the client’s ID in the clear (no password or secret key is sent ) • If TGS has the client in data base, it will returns an encrypted client/TGS session key in the secret key of the client and a TGT encrypted in the secret key of the TGS server • The client decrypts the message containing the session key with its secret key, and use it to communicate with the TGS server, and erases its stored secret key

13. Client to TGS Server: Request for service • When requesting access, the client sends two messages to the TGS server: • First it sends TGT, and the identification of the server(s) from which service is requested • Second message is an authenticator (the client ID, timestamp, and optional additional session key) encrypted in the assigned session key

14. TGS Server to Client: Issuing Ticket for service • The TGS server issues a ticket to the client that is encrypted in the server’s secret key, and a client/server session key that is encrypted in the client/TGS session key • Next to receive services, the client sends the ticket and authenticator to the server

15. Kerberos Vulnerabilities • Kerberos addresses the confidentiality and integrity of the information, but because all the secret keys are held and authentication is performed on the Kerberos TGS and authentication servers, they are vulnerable to physical and malicious code attacks • Replay attacks can be accomplished if the compromised tickets are used within an allotted time window • A client’s secret key, can be compromised as well as the session keys that are stored at the client’s computer • In Kerberos IV, DES was used for encryption (DES can be cracked), in current release (Kerberos V) support is provided for “plug-in” symmetric encryption algorithm (such as 3DES, IDEA)

16. Remote Access Dial-In User Service (RADIUS) • An authentication and accounting service • To access the network Username and password passed by the Network Access Server (NAS) to a RADIUS to be verified • In the wireless LAN, the APs play the roll of the NAS • RADIUS may use an internal or external database of users • RADIUS works just as well with VPNs in a wireless environment as it does with 802.1x/EAP

18. RADIUS server features include: • Scalability • EAP Support (TLS, TTLS, LEAP, MD5 ) • Clustering and Failover Support • Accounting • Legacy Authentication Protocol Support • Mutual Authentication Support • Multiple RAS Vendor Support • Software and Appliance Implementations

19. Scalability • RADIUS server’s ability to pass authentication requests to another authentication service such as another RADIUS server or an LDAP compliant user database • This is called Proxy Authentication

20. EAP support • RADIUS server should support the type of EAP that will be used in an organization • If not, choose the wireless infrastructure devices that support an EAP type matching the server

21. Clustering and Failover • Clustering means that multiple servers can run as a single computer where each shares in the workload of the application • Some RADIUS packages support clustering • Depending on the OS vendor, this may require additional licensing, upgrades and more

22. Accounting • The RADIUS server can maintain: • A history of all user dial-in sessions, indicating start time, stop time, and various statistics for the session • A current user list indicating which users are currently connected to which Remote Access Servers (RAS)

23. Legacy Authentication Protocols • Up-to-date RADIUS server software typically supports MS-CHAP, MS-CHAPv2, multiple EAP types, and other types of authentication • Support for legacy authentication protocols is sometimes desirable because of legacy RAS devices that are in place • Integrating both legacy and leading edge authentication protocols makes the transition between older and newer systems easier

24. Mutual Authentication • Both the client and the server must authenticate each others (two-way login) • In some cases mutual authentication also refers to both the client and access point having to authenticate to the authentication server • Mutual authentication eliminates man-in-the-middle and rogue access point attacks

25. Multiple RAS Vendors • When purchasing a RADIUS server package, make sure that the administrator can configure the server with the proper “dialect” RADIUS protocol that will work with the organization’s NAS

26. Various Implementations • RADIUS servers come in various forms: • Hardware appliances (suitable for large enterprises where distributed proxy RADIUS devices alleviate congested WAN links) • Software packages (Unix, Linux, Windows 2000 professional) for scalability and redundancy • Integrated into wireless infrastructure devices appropriate for SOHO environments where there are a small number of users

27. Authentication Design Considerations • Single Site deployment • Distributed autonomous sites • Distributed Sites, Centralized authentication & Security • Distributed Sites & Security, Centralized Authentication • Combination Architectures

28. Single Site Deployment • All WLAN users are located at a single site • A central authentication database handles all user authentication • One or more RADIUS servers manage WLAN and/or remote access use, authenticating users and setting up secure WLAN connections

29. Advantages of Single Site Deployment • You can authenticate your WLAN users against any back-end authentication database your RADIUS server supports • To scale, add access points and RADIUS/AAA servers to authenticate users against the central authentication database

30. Distributed Autonomous Sites • Distributed autonomous sites or networks • The authentication database is replicated from the central site downstream to each autonomous site or network, so that all user authentication happens locally • One or more RADIUS servers managing WLAN and/or remote access use are located at each autonomous site or network. • Each RADIUS server performs the following tasks: • Handles user authentication locally • Sets up secure WLAN connections • If required, records accounting data • Availability of central site network or hub is not an issue

31. Distributed Autonomous Sites • This architecture presents the following benefits: • Access to network is governed locally, and is not subject to the reliability of a link back to a central authentication store • The distributed RADIUS servers handle the full computational load associated with setting up the secure WLAN connection (you can easily add servers to absorb the performance hit associated with adding new WLAN users)

32. Distributed Sites, Centralized Authentication & Security • Distributed sites, networks or clusters of access points • WLAN access points at each site or on each network authenticate users against an authentication database located at a central site or operating hub • One or more RADIUS servers at the central site manage all WLAN and/or remote access use. • The central site RADIUS server: • Handles user authentication locally • Sets up secure WLAN connections • If required, records accounting data • Availability of central site network or hub is an issue • Link bandwidth usage may be an issue

33. Two issues that need considerationwhen DSCA&S is used • Ability of a WLAN user to connect to the network is dependent on the status of the link between the distributed networks and central site or operating hub • RADIUS/AAA server at central site responsible for authenticating users, it must also perform the cryptographic computations necessary to set up the secure WLAN connection (performance bottleneck!)

34. Distributes Sites & Security Centralized Authentication • Distributed sites, networks or clusters of access points • The authentication database is located at the central site or network hub

35. Distributes Sites & Security Centralized Authentication • One or more RADIUS servers managing WLAN and/or remote access use are located at each site, network, or AP cluster • The distributed RADIUS server performs the following tasks: • Queries the central site for user authentication • Handles setting up the secure connection itself • If required, records accounting data locally, or forwards data to the central site • Availability of central site network is an issue

36. Combined Architectures • 802.1x is very flexible • You can mix and match the different architectures presented before

37. EAP Types

38. LDAP • LDAP is lightweight version of the X.500 Directory Access Protocol • LDAP is a simple protocol that acts as a storehouse of information for applications • LDAP contains small records of information in a hierarchical structure

39. Native LDAP servers • OpenLDAP server (Linux ) • Innosoft’s Distributed Directory Server (Linux) • Netscape Directory server (Linux) • Sun Microsystems’s Directory Service (Solaris) • IBM’s DS Series LDAP Directory (AIX) • University of Michigan’s SLAPD (various forms of Unix)

40. LDAP applications and use • There are a number of other directory service systems that also support LDAP queries, where they use proprietary APIs with interfaces for LDAP communications • They are: • Novell’s eDirectory • Microsoft’s Active Directory • Lotus Domino • Many EWGs can query LDAP compliant databases directly rather than go through RADIUS

41. Uses for LDAP • A data retrieval protocol - used directly as an application server to retrieve information from a directory • An application service protocol - used by different applications to retrieve the information these applications require • An inter-application data exchange interface - used by one application to exchange data with another, or as a gateway between two incompatible applications • A system service protocol - used by an OS to communicate information between its different resources or components

42. LDAP 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 • 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

43. LDAP Architecture • The basic structure is a simple tree called the directory information tree (DIT) • Every node in the tree is known as an entry, or directory service entry (DSE) • There is a special entry called the root directory specific entry or rootDSE, that contains a description of the whole tree, its layout, and its contents, but this is not really the root (root does not exist) • To refer to each entry in the DIT uniquely, you must use a distinguished name (DN) • If you know the subset, you need only specify the name relative to it (RDNs relative distinguished names)

44. Multi-factor Authentication • There are three different types of authentication criteria that can be combined to create a multi-factor solution: • Knowledge-username/passwords (something you know) • Possessions- token, secureID, SmartCard (something you have) • Biometrics- fingerprints, eye scan, hand scan (something you are) • When choosing a solution you must consider • Management & integration , and • proven technology

45. Resources • CWSP certified wireless security professional, from McGraw-Hill