157
157
A 1GHz system will likely do 30 calculations/s. A 2Ghz system may
158
158
do 50 calculations/s, or more. That number is also the number of
159
159
authentications/s that can be done for EAP-TLS (or TTLS, or PEAP).
164
The certificates created using this method are known to be compatible
165
with ALL operating systems. Some common issues are:
167
- Windows requires certain OID's in the certificates. If it doesn't
168
see them, it will stop doing EAP. The most visibile effect is
169
that the client starts EAP, gets a few Access-Challenge packets,
170
and then a little while later re-starts EAP. If this happens, see
171
the FAQ, and the comments in raddb/eap.conf for how to fix it.
173
- Windows requires the root certificates to be on the client PC.
174
If it doesn't have them, you will see the same issue as above.
176
- Windows XP post SP2 has a bug where it has problems with
177
certificate chains. i.e. if the server certificate is an
178
intermediate one, and not a root one, then authentication will
179
silently fail, as above.
181
- Some versions of Windows CE cannot handle 4K RSA certificates.
182
They will (again) silently fail, as above.
184
- In none of these cases will Windows give the end user any
185
reasonable error message describing what went wrong. This leads
186
people to blame the RADIUS server. That blame is misplaced.
188
- Certificate chains of more than 64K bytes are known to not work.
189
This is a problem in FreeRADIUS. However, most clients cannot
190
handle 64K certificate chains. Most Access Points will shut down
191
the EAP session after about 50 round trips, while 64K certificate
192
chains will take about 60 round trips. So don't use large
193
certificate chains. They will only work after everyone upgrade
194
everything in the network.
196
- All other operating systems are known to work with EAP and
197
FreeRADIUS. This includes Linux, *BSD, Mac OS X, Solaris,
198
Symbian, along with all known embedded systems, phones, WiFi
201
- Someone needs to ask Microsoft to please stop making life hard for
205
SECURITY CONSIDERATIONS
207
The default certificate configuration files uses MD5 for message
208
digests, to maintain compatibility with network equipment that
209
supports only this algorithm.
211
MD5 has known weaknesses and is discouraged in favor of SHA1 (see
212
http://www.kb.cert.org/vuls/id/836068 for details). If your network
213
equipment supports the SHA1 signature algorithm, we recommend that you
214
change the "ca.cnf", "server.cnf", and "client.cnf" files to specify
215
the use of SHA1 for the certificates. To do this, change the
216
'default_md' entry in those files from 'md5' to 'sha1'.