Digital Certificates

[Kenny]

in a WLAN using 802.1x/EAP-TLS authentication is by means of digital certificates (X.509) - does anyone know how to apply for a digital certificate?, can someone also confim that to use 802.11x/EAP-TLS you require a PKI infrastructure?

[oshea85]

You can install a private certificate server as an option when you build a Win 2K server. It's not real hard to set up the server and install the certificates on clients, but it can become a real bear to manage in an implementation of any size. You need to think hard about it before you implement this.

And, yes, you do need PKI to do EAP-TLS. The catch with EAP-TLS is that you need a certificate for each user on any machine that they may use to access the network. This is OK for enterprises, but not very workable for schools or hospitals.

PEAP (Protected EAP) will eventually allow you to do tunnelled username/password authentications, among other types. Cisco implemented this on their client software and Access Control Server and M$ built in a PEAP client into Win2K SP 3 and WinXP SP1. The rub is that M$ implemented PEAP to only work with MS-CHAP passwords, so you can only use it to authenticate against NT or AD domains, and M$ has no PEAP server yet! Bastards... I have so many schools looking to authenticate their wireless users against NDS...

Sorry about the rant...

[Kenny]

I was under the impression that EAP-PEAP would be identical to EAP-TTLS but used dual certificates - not user name/password, are you saying that is you use a MS Server OS then you can only use MS-CHAP to authenticate? - I am not very up on the server side of things so aplogies if I am making no sense!

Also regarding the certificates, if you set install a private certificate server under Win 2K server is this not classed as "self issued" and therefore cannot be trusted 100%, for this I assume you would have to pay someone like VeriSign for the pleasure?

Thx for the info.

[oshea85]

EAP-TLS uses client - and server- side certificates. EAP-TTLS uses a server-side certifcate only, and a username/password; downside is having to install that Funk client software and server certificate on every laptop; three weeks after you leave the site and a user can't print, you touched his machine last, so guess who gets the phone call? Try not to get any on you...

What I'm saying is that PEAP was supposed to support almost any type of authentication, against almost any type of user database. M$ only chose to implement the portions of PEAP that directly supported them, and nothing else.

If it's your private certificate authority, and you trust it, who cares? In this architecture, you have to know everyone, and they have to know you (liike an enterprise). You are going to be touching every single machine, for every single user on that machine. This is a hard sell to many organizations.

LEAP, or PEAP, or EAP-TTLs, are more attractive many times, due to the ease of deployment and use. Leap gives you an integrated wireless/NOS logon (very, very nice) that's easy to install and manage, and is pretty secure, not bulletproof (what is?). Peap is damn strong supposedly, and pretty easy to implement, very flexible, and the client-side is supported by M$ (with the previous caveats), so you don't have to touch the client machines much, if at all; downside is there is no M$ or open source PEAP server yet (that I know of, only Cisco has one).

[Kenny]

so you would recommend the use of EAP-TTLS or PEAP or LEAP (for Cisco infrastructure) - due to ease of installation / maintainence?

One last thing, is it true that only Funk and Meetinghouse Data are the only two vendors that support both TLS and TTLS with Meetinghouse the only one to support the client (AEGIS) under Linux?.

Cheers.

[moe]

sorry if i get in the middle of your conversation, but since i am interested in learning a way to cipher the data transimetted in the radio link i read your post.
So in order to recap:
TLS needs certificated on both sides (client and server) - that means that it is very hard to deploy in a large scale
TTLS needs a certificate only on the server side but does the client need any kind of software?
PEAP needs a client software that at the moment is included in what/where, and what versions?

Other questions that i have (you look like you are experts, so sorry if i am a newbie :-p
- what is the thing that you say about MS supporting PEAP only for MS CHAP passwords? What does it mean? Actually what are MS CHAP pwds?
- does PEAP allow to crypt the traffic or it is useful only in the auth phase?

I am asking this because i am trying to use EAP/SIM for authentication and then somehow crypt the traffic in the radio link.

Thanks!
/mm

[Kenny]

Yes - TTLS uses a certificate on the server side but on the client side only a user name and password is used. In order to use TTLS you will need software on the Client, this is available from Funk (Odyssey Client) or Meetinghouse Data (Aegis)

PEAP is auth only - encryption will still be via WEP.

What this means that MS's implementation of PEAP is user name and password via MS CHAP only, this means that you can only auth to MS NT and AD domains.

MS CHAP (Microsoft Challenge Handshake Authentication Protocol) is not actually a password, it is the protocol by which a client exchanges a user name and password with the auth server.
eg LEAP uses MS CHAP ver1 to pass user name/pass through the AP to the server, TTLS uses PAP, CHAP, MS CHAP v1, v2.

thx

[moe]

so PEAP is only for auth? Wow, i thought it was to cipher the data in the radio link....
so in what way can i cipher the traffic? Only TLS and TTLS right?
As for you what you say TTLS is better because you only need to install a certificate on the server side. But what about the client? Do you have to install that software even under windows XP, or it's already supported?

[Kenny]

All the EAP extensions such as PEAP/LEAP/TLS/TTLS/MD5 are for auth only, they play no part in encryption - all encryption is done via WEP (64 or 128bit).

The advantage of having encryption with auth is that the WEP keys are dynamic - that is every time you are auth to the server a new key pair is generated (not MD5). In WLAN's that use only encryption via WEP the keys are static and do not change, this makes it more prone to various types of hacks.

As for support:
TLS - native to XP with W2K drivers available
TTLS - developed by Funk as an alternative to TLS - client software required
LEAP - Cisco hardware/software required
PEAP - PEAP client built into W2K SP 3 and WinXP SP1

TTLS is a better solution (than TLS) as certificates are only required server side, this makes it an easier solution to manage, problem is though you have to install the client software on every laptop on the wlan.

[moe]

but if encryption is still made with keys, there must be someone that sets all the WEP keys on the clients, am i right?

[Kenny]

There are two different systems, static and dynamic key generation:

1. static key generation (WEP system with no auth) is where the keys have to be entered into the wlan setup utility manually, a max of 4 keys can be used, the client has 4 keys and the AP has 4 keys, it is not necessary for both sides (typically, an access point and a client station) to have the same set of 4 keys. As long as there is one key in common, they can communicate if they both use that common key.

2. dynamic key generation (WEP encryption with auth) is at is sounds, as part of the log-in/auth process, clients dynamically generate a new WEP key instead of using a static key, all clients have unique keys.

thx