Phase 2 on PEAP and EAP-TTLS

[Panagiotis Georgopoulos]

Hello all,



For EAP-MSCHAPv2 in Phase 2 of EAP-TTLS , I have to declare
to wpa_supplicant Phase2="autheap=MSCHAPV2".



For PEAP though, if I do :



phase1="peaplabel=1"

phase2="auth=MSCHAPV2" (notice that it is just auth, and not
autheap)



will I be doing mschapv2 or eap-mschapv2 on Phase 2?



If I am right PEAP supports only EAP methods for Phase 2, so
the two above configurations should have exactly the same phase 2, right?



Thanks a lot in advance,

Panos

[Jouni Malinen]

Post by Panagiotis Georgopoulos
For EAP-MSCHAPv2 in Phase 2 of EAP-TTLS , I have to declare
to wpa_supplicant Phase2="autheap=MSCHAPV2".
phase1="peaplabel=1"

Are you sure the authentication server is using the new PEAP label? Most
servers don't.

Post by Panagiotis Georgopoulos
phase2="auth=MSCHAPV2" (notice that it is just auth, and not
autheap)
will I be doing mschapv2 or eap-mschapv2 on Phase 2?

Well.. Depends on what you want to call the stuff that PEAP does (it may
end up removing the EAP headers from Phase 2).. But anyway, it is
EAP-MSCHAPv2 -based.

Post by Panagiotis Georgopoulos
If I am right PEAP supports only EAP methods for Phase 2, so
the two above configurations should have exactly the same phase 2, right?

EAP-TTLS is the odd one with option for both EAP and non-EAP Phase 2
methods and as such, need to have different specification for MSCHAPv2
(without EAP) and EAP-MSCHAPv2. PEAP and EAP-FAST use the auth=<EAP
method name> selection.

[Panagiotis Georgopoulos]

Hello Jouni,

Thanks for your reply, please see my answers inline.

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
For EAP-MSCHAPv2 in Phase 2 of EAP-TTLS , I have to declare
to wpa_supplicant Phase2="autheap=MSCHAPV2".
phase1="peaplabel=1"

Are you sure the authentication server is using the new PEAP label?
Most servers don't.

Well, I am using FreeRadius 2.1.10 and I see no warnings or errors on the
FR's output regarding label=1 and the authentication finishes successfully.
Shouldn't I have seen an error/warning somewhere in the output?

I am afraid I am unable to find whether the new label is supported on
freeradius' website...

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
phase2="auth=MSCHAPV2" (notice that it is just auth, and not autheap)
will I be doing mschapv2 or eap-mschapv2 on Phase 2?

Well.. Depends on what you want to call the stuff that PEAP does (it
may end up removing the EAP headers from Phase 2).. But anyway, it is
EAP-MSCHAPv2 -based.

Well.. since in theory PEAP is using only EAP based methods in Phase 2, I am
thinking that setting phase2="auth=MSCHAPV2" it would do EAP-MSCHAPv2. Your
characterization as "based" worries me a little...:-D

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
If I am right PEAP supports only EAP methods for Phase 2, so
the two above configurations should have exactly the same phase 2, right?

EAP-TTLS is the odd one with option for both EAP and non-EAP Phase 2
methods and as such, need to have different specification for MSCHAPv2
(without EAP) and EAP-MSCHAPv2. PEAP and EAP-FAST use the auth=<EAP
method name> selection.

I totally see your point, thus is the reason I think, you consider valid
options both auth=MSCHAPv2 and autheap=MSCHAPv2 for EAP-TTLS in phase2 to
distinguish between plain mschapv2 and eap-mschapv2, right? This is exactly
what I wanted to clarify...

On a similar note, would the EAP-PEAP/MSHAPv2 and EAP-TTLS/EAP-MSCHAPv2 have
exactly the same second phase? In theory, when they both establish a secure
channel in Phase 1 using their respective mechanisms, they should have
identical phase2 based on EAP-MSCHAPv2. Right or wrong?

Thanks a lot,
Panos

[Jouni Malinen]

Post by Panagiotis Georgopoulos

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
phase1="peaplabel=1"

Are you sure the authentication server is using the new PEAP label?
Most servers don't.

Well, I am using FreeRadius 2.1.10 and I see no warnings or errors on the
FR's output regarding label=1 and the authentication finishes successfully.
Shouldn't I have seen an error/warning somewhere in the output?

Not on the RADIUS server. The authentication part goes through just
fine, but the derived keys are different and should you use this, e.g.,
for WPA2-Enterprise, the peer would fail to complete the connection
because of the mismatch in the keys.

Post by Panagiotis Georgopoulos
I am afraid I am unable to find whether the new label is supported on
freeradius' website...

It doesn't. It is safe to assume that more or less whatever server you
would use, it will not use the new label with PEAPv0 or even with
PEAPv1. There are only couple of exceptions to this rule and those are
not exactly popular authentication servers.

Post by Panagiotis Georgopoulos
Well.. since in theory PEAP is using only EAP based methods in Phase 2, I am
thinking that setting phase2="auth=MSCHAPV2" it would do EAP-MSCHAPv2. Your
characterization as "based" worries me a little...:-D

Worry about what? Why would be different if it were MSCHAPv2 without EAP
encapsulation? Anyway, yes, it is EAP-MSCHAPv2 of which the PEAP
encapsulation removes parts of the tunneled EAP header.

Post by Panagiotis Georgopoulos
I totally see your point, thus is the reason I think, you consider valid
options both auth=MSCHAPv2 and autheap=MSCHAPv2 for EAP-TTLS in phase2 to
distinguish between plain mschapv2 and eap-mschapv2, right? This is exactly
what I wanted to clarify...

Correct (or well, with the clarification that the correct spelling of
that in auth/autheap parameters is with upper case 'v', i.e.,
"MSCHAPV2").

Post by Panagiotis Georgopoulos
On a similar note, would the EAP-PEAP/MSHAPv2 and EAP-TTLS/EAP-MSCHAPv2 have
exactly the same second phase? In theory, when they both establish a secure
channel in Phase 1 using their respective mechanisms, they should have
identical phase2 based on EAP-MSCHAPv2. Right or wrong?

It sort of depends on how strict you want to be with "exactly the
same".. ;-) Depending on PEAP version, the inner EAP-MSCHAPv2 EAP header
may be modified. The payload of the inner method is identical. Though,
you may also want to note that it is actually not identical in case of
EAP-FAST/EAP-MSCHAPv2 which uses implicit challenge from Phase 1 in the
Phase 2 EAP-MSCHAPv2.

[Panagiotis Georgopoulos]

Hello Jouni, Alan,

Thanks for your replies, please se my answers below.

Post by Jouni Malinen

Post by Panagiotis Georgopoulos

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
phase1="peaplabel=1"

Are you sure the authentication server is using the new PEAP label?
Most servers don't.

Well, I am using FreeRadius 2.1.10 and I see no warnings or errors on
the FR's output regarding label=1 and the authentication finishes

successfully.

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
Shouldn't I have seen an error/warning somewhere in the output?

Not on the RADIUS server. The authentication part goes through just
fine, but the derived keys are different and should you use this, e.g.,
for WPA2-Enterprise, the peer would fail to complete the connection
because of the mismatch in the keys.

Well, interestingly the keys negotiation between the Client (wpa_supplicant)
and Access Point (hostapd 0.7.3) finishes successfully.

However, prompted by Alan's email that FR doesn't do PEAPv1, I looked into
the packets in Wireshark and I indeed see that the server requests PEAP
version 0 which I am guessing the client complies with.

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
Well.. since in theory PEAP is using only EAP based methods in Phase
2, I am thinking that setting phase2="auth=MSCHAPV2" it would do

EAP-MSCHAPv2. Your

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
characterization as "based" worries me a little...:-D

Worry about what? Why would be different if it were MSCHAPv2 without
EAP encapsulation? Anyway, yes, it is EAP-MSCHAPv2 of which the PEAP
encapsulation removes parts of the tunneled EAP header.

Well, that is the problem I am having.. I see different behaviour on the
FR's side when using PEAP/MSCHAPv2 and EAP-TTLS/EAP-MSCHAPv2 in Phase 2. I
am noticing two pairs of MS-MPEE keys in the Access-Accept message sent by
FR (see below) when I am using EAP-TTLS/EAP-MSCHAPv2 which I don't have when
I use PEAP/MSCHAPv2...

Sending Access-Accept of id 52 to 2001:db95::100 port 1814
Reply-Message = "Hello, bob-mr1"
MS-MPPE-Encryption-Policy = 0x00000001
MS-MPPE-Encryption-Types = 0x00000006
MS-MPPE-Send-Key = 0x8566119a6066e8eb7c1663dea8d1629b
MS-MPPE-Recv-Key = 0xc1f99bac753248c48db73fd5585bf810
Message-Authenticator = 0x00000000000000000000000000000000
User-Name = "bob-mr1"
MS-MPPE-Recv-Key =
0x2eb89da2ac20179cb2b99391f94ca2bddf1701c67c524badad98ce56f09873dc
MS-MPPE-Send-Key =
0x0cf013411cfcea14ae9dee56baaf5467e55caed80fa83ffbbdf0f5998ce7fe62
EAP-Message = 0x03cf0004
Proxy-State = 0x3130

(My full email to FR's mailing list if you need more information is here :
https://lists.freeradius.org/pipermail/freeradius-users/2010-November/msg002
39.html )

So, I am trying to investigate why I am getting 2 MS-MPEE keys on
EAP-TTLS/EAP-MSCHAPv2 and not on PEAP/MSCHAPv2 although theoretically they
follow the same (or very similar) process...

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
I totally see your point, thus is the reason I think, you consider
valid options both auth=MSCHAPv2 and autheap=MSCHAPv2 for EAP-TTLS in
phase2 to distinguish between plain mschapv2 and eap-mschapv2, right?

This is

Post by Jouni Malinen

Post by Panagiotis Georgopoulos
exactly what I wanted to clarify...

Correct (or well, with the clarification that the correct spelling of
that in auth/autheap parameters is with upper case 'v', i.e.,
"MSCHAPV2").

Sure ;-)

Cheers,
Panos

[Alan DeKok]

Post by Panagiotis Georgopoulos
Well, that is the problem I am having.. I see different behaviour on the
FR's side when using PEAP/MSCHAPv2 and EAP-TTLS/EAP-MSCHAPv2 in Phase 2. I
am noticing two pairs of MS-MPEE keys in the Access-Accept message sent by
FR (see below) when I am using EAP-TTLS/EAP-MSCHAPv2 which I don't have when
I use PEAP/MSCHAPv2...

I don't recall seeing that problem in my config. So...

Post by Panagiotis Georgopoulos
So, I am trying to investigate why I am getting 2 MS-MPEE keys on
EAP-TTLS/EAP-MSCHAPv2 and not on PEAP/MSCHAPv2 although theoretically they
follow the same (or very similar) process...

You can configure FreeRADIUS to filter the extra attributes. This
isn't a problem with wpasupplicant.

Alan DeKok.

[Panagiotis Georgopoulos]

Post by Alan DeKok

Post by Panagiotis Georgopoulos
Well, that is the problem I am having.. I see different behaviour on
the FR's side when using PEAP/MSCHAPv2 and EAP-TTLS/EAP-MSCHAPv2 in

Phase

Post by Alan DeKok

Post by Panagiotis Georgopoulos
2. I am noticing two pairs of MS-MPEE keys in the Access-Accept message
sent by FR (see below) when I am using EAP-TTLS/EAP-MSCHAPv2 which I

don't

Post by Alan DeKok

Post by Panagiotis Georgopoulos
have when I use PEAP/MSCHAPv2...

I don't recall seeing that problem in my config. So...

Well, I've posted on FR's mailing list with a full debug output from my
setup if you want to follow up.

Post by Alan DeKok

Post by Panagiotis Georgopoulos
So, I am trying to investigate why I am getting 2 MS-MPEE keys on
EAP-TTLS/EAP-MSCHAPv2 and not on PEAP/MSCHAPv2 although theoretically
they follow the same (or very similar) process...

You can configure FreeRADIUS to filter the extra attributes.

Yes I can, but the fact that you don't see this in your setup is more
worrying. Don't take me wrong, it is a good thing that there is a solution
to my problem, but it would have been better if I didn't have the problem in
the first place!

Post by Alan DeKok
This isn't a problem with wpasupplicant.
Alan DeKok.

Well, I was trying to verify that my configuration with PEAP and EAP-TTLS in
Phase 2 is correct in wpa_supplicant and that it is doing in Phase2 what I
am expecting it to do. Now I can focus more on the FR's side of things.

Thank you both for your replies,
Panos

[Alan DeKok]

Post by Panagiotis Georgopoulos

Post by Jouni Malinen
Are you sure the authentication server is using the new PEAP label?
Most servers don't.

Well, I am using FreeRadius 2.1.10 and I see no warnings or errors on the
FR's output regarding label=1 and the authentication finishes successfully.

FreeRADIUS negotiates PEAPv0, in which case the label is not usd.

Post by Panagiotis Georgopoulos
I am afraid I am unable to find whether the new label is supported on
freeradius' website...

FreeRADIUS implements PEAPv0 only.

Alan DeKok.