1X on the AirPort

X on the AirPort

802.1X on Panther is set up through the Internet Connect application, which can be launched from the drop-down menu under the AirPort status icon, or directly from the hard disk.

To see the 802.1X configuration, click on the lock labeled 802.1X. If the lock does not appear, either select New 802.1X Configuration from the File menu, or press Command-Shift-X. Once 802.1X has been displayed for the first time, it will always appear as an icon across the top (Figure 18-10).

To see the full configuration, select the Configuration drop down menu and choose Edit Configuration..., which brings up the main configuration screen (Figure 18-11). The easiest task from here is to edit the configuration. This brings up a configuration screen. Put in the username and password, and select any authentication protocols that may be used. This screen allows selection of the network interface to which the 802.1X credentials apply. In most cases, it will remain set to the AirPort card, although wired 802.1X is gaining prominence. The username and password are straightforward, as is the wireless network. By default, the drop down for Wireless Network will display any encrypted networks detected by the AirPort, but it is possible to type in an arbitrary SSID.

Figure 18-7. TCP/IP preferences tab of the Network Preferences settings

After typing in credentials, it may be necessary to configure the authentication method. The supplicant has different configuration screens for each method, as discussed in subsequent sections.

After returning to the main screen of Internet Connect, you can press the Connect button to associate to the network and attempt 802.1X authentication. The status bar at the bottom will go through the following stages:

Figure 18-8. AirPort preferences tab of the Network Preferences settings

 

Idle

The AirPort is not associated to any network.

Connecting

The AirPort is associating with the selected SSID.

Authenticating

The AirPort is trading EAPOL frames with the AP or switch as it tries to validate user credentials.

Connected via (EAP method)

If the authentication succeeds, the status bar will note that the system is connected, and it will display the EAP method in use, as well as the time which the system has been authenticated.

Figure 18-9. Internet Connect monitoring application

Figure 18-10. 802.1X configuration in Internet Connect

 

Configuring EAP Methods

Each of the EAP methods has a different method configuration. Generally speaking, the Mac supplicant hides a great deal of the complexity, unless it is required.

TTLS configuration

There are two potential TTLS configuration options, shown in Figure 18-12. The first, which is mandatory, is the inner authentication type. In most cases, I expect this will be set to PAP, though it is also possible to use CHAP, MS-CHAP, or MS-CHAP-V2. Like most supplicants, the Mac supplicant supports hiding the user identity by configuring an anonymous outer identity.

Figure 18-11. 802.1X Configuration screen

Figure 18-12. TTLS configuration screen

 

PEAP configuration

On the Mac supplicant, only EAP-MSCHAP-V2 is supported as an inner authentication method. This allows interoperability with user accounts stored as MD4 hashes or in cleartext. The main use for this method is to support user accounts stored in a Windows network. On the configuration screen, Figure 18-13, the only option is to configure an outer identity to hide the user identity.

The Keychain

In Mac OS, passwords and certificates are stored on a keychain, which holds security-relevant information in a centralized location. By logging in, the certificates and user credentials required for network authentication are available to any application allowed by the user. Figure 18-14 shows a simple keychain, which contains one RADIUS server certificate, the CA that signed that certificate, and the 802.1X configuration for a network. The keychain provides access control to protect configurations.

Figure 18-13. PEAP configuration screen

Figure 18-14. The keychain viewer

 

Adding to the keychain

When connecting to an 802.1X-protected network for the first time, any certificates that are not yet trusted will cause the authentication to fail. Rather than failing the authentication, the supplicant will present the certificates to the user, as shown in Figure 18-15. By inspecting the certificates, users can make a decision about whether to trust them. More likely, a centralized information technology department will test user credentials on the wireless network before turning the system over to the end user, and can add any relevant certificates during the build process.

Figure 18-15. Adding a certificate to the keychain

 

Troubleshooting

When 802.1X authentication fails, the message that is received (Figure 18-16) does not provide a great deal of information. An error code does not provide detailed diagnostic information about why the failure has occurred.

Figure 18-16. X failure dialog box

Fortunately, the supplicant is capable of producing extensive debug logging. Create the directory /var/log/eapolclient. If the directory exists and the NSDebugEnabled environment variable is set when Internet Connect launches, it will log EAPOL frames from the user to /var/log/eapolclient/uid(number)-(network interface).log. For example, if UID 501 attempts to use 802.1X on the AirPort (typically en1), the file will be uid501-en1.log. Internet Connect must be launched from the command line to pick up the environment variable in the Terminal it is launched from.

 Mac:~$ sudo mkdir /var/log/eapolclient
 Mac:~$ NSDebugEnabled=YES; export NSDebugEnabled
 Mac:~$ /Applications/Internet Connect.app/Contents/MacOS/Internet Connect

The debug log will dump out every frame sent and received, in both ASCII and hexadecimal. It does not print decrypted frames for EAP methods that use encryption. As an example, the following two EAPOL-Key frames were received after a successful 802.1X authentication:

 ----------------------------------------
 2005/02/15 17:00:42.903841 Receive Packet Size: 75

 Ether packet: dest 0:30:65:2:e7:36 source 0:b:e:a:70:2 type 0x888e
 EAPOL: proto version 0x1 type Key (3) length 57
 Signature: 6c 08 b3 97 b1 74 f2 ec 0e 2c 1f 66 ff 40 78 42 is valid
 EAPOL Key Descriptor: type RC4 (1) length 13 Broadcast index 2
 replay_counter: 42 11 48 e2 00 00 00 18
 key_IV: ca 7e d9 ff d4 47 80 ba 9e eb 33 c8 82 17 02 7c
 key_signature: 6c 08 b3 97 b1 74 f2 ec 0e 2c 1f 66 ff 40 78 42
 key: fc 7a 7c 67 f6 f6 f5 7d a5 94 cb 49 1a

 ----------------------------------------
 2005/02/15 17:00:42.960436 Receive Packet Size: 64

 Ether packet: dest 0:30:65:2:e7:36 source 0:b:e:a:70:2 type 0x888e
 EAPOL: proto version 0x1 type Key (3) length 44
 Signature: ce b3 45 05 47 72 5a 98 7c 64 0c d8 52 0d 8f 78 is valid
 EAPOL Key Descriptor: type RC4 (1) length 13 Unicast index 0
 replay_counter: 42 11 48 e2 00 00 00 19
 key_IV: 45 e5 2a ad 1c 9c ea 8f 3c 58 a4 c4 6a e0 fa 82
 key_signature: ce b3 45 05 47 72 5a 98 7c 64 0c d8 52 0d 8f 78
 EAPOL: 2 bytes follow body:
 0000 00 00 

Mixing WPA and WEP on the Mac

As this book went to press, the Mac supplicant had a bug related to the interoperability in environments which mix encryption types. It is relatively common to run dynamic WEP and TKIP simultaneously. Stations that are capable of TKIP run it for unicast data, while broadcast data is encrypted with dynamic WEP. Stations that are only capable of dynamic WEP use it for both unicast and broadcast data.

In a mixed WEP/TKIP environment, Macintoshes are unable to connected to the network. During the association process, the supplicant learns the network supports both WEP and TKIP, and accepts the security parameters by associating. However, during the key handshake, the supplicant insists on running only TKIP. With two different sets of security parameters in the association process and the keying process, the standards dictate that the AP should fail keying and kick the system off the network.

As a workaround, either reduce the security of the network to run only dynamic WEP, run two parallel wireless networks (one WEP and one TKIP) so that Macs can use a TKIP-only network, or force all dynamic WEP devices off the network until they can be upgraded to TKIP.