For windows 95/98 you could download the microsoft hotfixes, which add 802.1x support to these early versions of windows.
They include EAP-TLS and PEAP-MSCHAPv2 support. This is a much more secure approach than using a captive portal. Captive portals work well to authenticate a casual user, but will not deter fairly simple hacker attacks. Simon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Malewski Sent: Monday, February 10, 2003 2:13 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [BAWUG] What are Requirements for AP to support 802.1x/EAP Authentication ? Yes, 802.1x is a great idea, but it's hard to find Free clients (for Windows 95/98 users) Why not go with some form of web-based captive portal (NoCat), combined with a FreeRADIUS authentication RADIUS server? (like we're currently using) If this is something you'd be interested in working together on, I'd be more than happy to help/share ideas. We're currently working on a free "Global" authentication server, where communities would each run a copy of the software, and it would allow users to roam freely between communities (with one login and one password). The user databases would be "shared" between communities. www.nextechwireless.net If you're a developer, or would be interested in helping with the project, please drop me an E-mail off-list. Thanks, Mark -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of visakhae Sent: Saturday, February 08, 2003 10:08 AM To: 'Jacques Caron'; 'MAILING LIST Bawug WIRELESS' Subject: [BAWUG] What are Requirements for AP to support 802.1x/EAP Authentication ? Hello All, To Jacques: Hi, thanks a lot for ur answers on dynamic key mapping and Host based AP and firmware based AP. Please can anyone suggest me the following: If an AP is to be built, then what are the essential requirements that it has to support in order to be able to support 802.1x/EAP-Types(TLS, MD5) Authentications with RADIUS server as the Authentication server. Actually what mechanism is to be followed for the 802.1x/EAP-TLS authentication using RADIUS. This scenario is being followed in two different ways. Approach 1: The RADIUS server passes two keys to AP through MS-MPPE-Send-Key and MS-MPPE-Recv-key. These are the Session-Key and the Signing-key. The AP then sends two EAPOL-key messages (one EAPOL-Key message with empty key field for specifying that the session key derived is during EAP Authentication is the Unicast_Session-Key, and second EAPOL-Key message with the the broadcast-key(static/dynamic) which is Signed with the Signing-key and Encrpyted using the Session-Key. Approach 2: The RADIUS server passes one key to AP using MS-MPPE-Send-Key attribute in the Access-Accept Radius packet. The one key sent is the Session-Key. The AP then sends two EAPOL-key messages (one EAPOL-Key message with empty key field for specifying that the session key derived is during EAP Authentication is the Unicast_Session-Key, and second EAPOL-Key message with the the broadcast-key(static/dynamic) which is both Signed and Encrpyted using the Session-Key. Which is the better Approch to be followed so that the AP is compliant with i) most of the or with the standard RADIUS servers that support 802.1x/EAP-Types(TLS, MD5) Authentication ii) the WLAN Client products available in the market that support 802.1x/EAP-Types(TLS, MD5) Authentication [Do the client WLAN products require to support the 802.1x/EAP-Types(TLS, MD5) Authentication? ] Please explain me on this. Thanks in advance. regards, Visakha. ************************************************************************ *** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ************************************************************************ *** -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
