Forum

I've been reading Chapter 11, Data Link Security Solutions, in the CWSP study guide, and I still have the following questions on 802.1X and EAP:

1) LEAP: In the diagram on page 256 of the CWSP study guide, it appears that the authentication server authenticates the client *before* the client authenticates the authentication server. Isn't this insecure? Couldn't someone impersonate the authentication server and steal client credentials? Is this a weakness of LEAP?

2) LEAP only supports password authentication. Therefore, the strength of LEAP depends on the strength of the passwords chosen. Is the user ID exchange protected the way it is with EAP-TTLS and PEAP? If so, how is it protected? the table on page 261 only lists EAP-TLS, EAP-TTLS, and PEAP, with only TTLS and PEAP protecting the user ID exchange. I think I read somewhere in this forum that LEAP does *not* protect user ID exchange.

3) Does TTLS support fragmentation and reassembly?

4) Does LEAP support fragmentation and reassembly?

5) Does LEAP support fast session reconnect?

6) On page 270, figure 11.17, under client certificates, PEAP and TTLS say "No", as in no client certificates. However, on page 261, figure 11.14, under Client Certificate, EAP-TTLS and PEAP say "Optional". Which one is it? My take is that you can optionally use client-side certificates in both.

7) In the same figure (11.14), under authentication methods, EAP-TTLS lists (CHAP, PAP, MS-CHAP, MS-CHAPV2, and EAP. PEAP lists "Any EAP method". Does this mean that TTLS supports all the same EAP methods that PEAP does, plus the legacy ones (PAP, CHAP, etc).?

8) On page 265 of the study guide, it states that there are two types of PEAP that Microsoft supports: MS-CHAPV2-based, and TLS-based. With the TLS-based version, both client and server side certificates are required. with MS-CHAPV2, you can use a password or certficate on the client.

The guide states that MS-CHAPv2 apart from PEAP only supports password authentication. Question: Does this mean that you can't use certificates with the EAP-TTLS version of MS-CHAPV2?

9) In this forum, David Coleman states that there is also a distinction between Cisco PEAP and Bill Gate's PEAP (BGP), and that Cisco uses EAP-GTC inside of the TLS tunnel.

So is the real breakdown of supported EAP authentication types inside the tunnel for PEAP like this:

MS PEAP: MS-CHAPV2, TLS

Cisco PEAP: EAP-GTC, EAP-TLS, what else?

10) In this forum, David Coleman states that only Cisco's version of PEAP hides the user name: MS's version does not. This would seem to contradict the study guide in that MS PEAP supports TLS inside of the TLS tunnel, although this would be consistent in the way that EAP-TLS does not hide the user identity. Is the user ID always unprotected in all forms of MS PEAP, including PEAP-EAP-TLS?

Finally, I found the description of PEAP on page 262 of the CWSP study guide to be somewhat inaccurate and confusing:

"PEAP provides support for identity protection by using TLS to create an encrypted tunnel from the authentication server to the supplicant after verifying the identity of the authentication server."

This should be amended to say that this only applies to the Cisco version of PEAP.

Furthermore,

"PEAP extends a TLS connection, and once the encrypted tunnel is established, a second authorization process occurs inside the tunnel. The client is authenticated in the second EAP authentication running inside the TLS connection using any implemented EAP authorization type (tokens, passwords, certificates, etc)."

The use of the term authorization here is confusing: It should read something like

PEAP extends a TLS connection, and once the encrypted tunnel is established, a second authentication process occurs inside the tunnel. The client is authenticated in the second EAP session running inside the TLS connection using any implemented EAP authentication type (tokens, passwords, certificates, etc)

Where you substitute the term authentication for authorization.


Thanks,

MK

In this forum, David Coleman states that there is also a distinction between Cisco PEAP and Bill Gate's PEAP (BGP), and that Cisco uses EAP-GTC inside of the TLS tunnel.

So is the real breakdown of supported EAP authentication types inside the tunnel for PEAP like this:

The study guide is a little outdated. Cisco implementation of PEAP uses EAP-GTC inside the tunnel. When using EAP-GTC(Generic Token Card) inside the tunnel, the user creditionals can either be user name/password or a token card.

Microsoft implementation of PEAP uses MS-Chap ver2 inside the tunnel to authenticate user names and passwords.

Lots of vendors support BOTH flavors of inner-tunnel authentication of the user creditionals including the Cisco client utilities for the Cisco ABG card.

Microsoft's horrible client utilty called the Wireless Zero Configuration service only supports MS-Chap ver2 inside the tunnel.

Furthermore, if you are using a Cisco 350 B only card and install PEAP. It is not in the client utlity... what it does is install EAP-GTC for use with the Windows WZC client utilty. You must use the Windows supplicant to use PEAP with the Cisco B card.

In this forum, David Coleman states that only Cisco's version of PEAP hides the user name: MS's version does not. This would seem to contradict the study guide in that MS PEAP supports TLS inside of the TLS tunnel, although this would be consistent in the way that EAP-TLS does not hide the user identity. Is the user ID always unprotected in all forms of MS PEAP, including PEAP-EAP-TLS?

The issue is how the vendor implements PEAP... most vendors implement it properly and in thier client utilites there is a place to enter a "bogus" user name. The bogus user name is the one that is seen in clear text outside of the tunnel. Due to the 802.1x framework a user name will ALWAYS pass in the clear in an EAPOL-RESPONSE frame with every flavor of EAP. However with EAP-TTLS and EAP-PEAP another user name(the real user name) is protected inside the TLS tunnel.

Sadly, some vendors including our friends at Microsoft... actually pass the real user name both inside the tunnel and outside the tunnel when using PEAP. :(

Bottom line.... do not ever use the Microsoft supplicant... it is hideous for a number of reasons. Hope that your vendors client utlities implement PEAP properly or even better purchase the third-party Odyssey client from Funk Software which supports every major type of EAP that exists.

Mr. Multipath, you Sir are a Wireless Networking Genius. I love your post! I have been gleaning from them all day. Thanks for your expertise.

compughter

Thanks but I am not a genius... just have dealt with PEAP a zillion times :-)

Maybe David should change his user name to PEAPing Tom. ;-P