Wireless PEAP/MSCHAPV2 client programming question

Howdy,

I am writing an 802.1x wireless client program that will (I hope) support
authentication using PEAP/MSCHAPV2 authentication. I have a question, but
first please let me tell you where I am, then I will state my question:

I have a complete phase 1 of PEAP and have a working TLS tunnel. Through
this tunnel I receive what I'm pretty sure is the MSCHAPV2 eight byte server
challenge.

I then construct the 49 byte client response per the MSCHAP specficiation.
I think my basic crypto code is correct, because when I run the test vectors
that are included with the open source WPA_Supplicant program I get the same
results.

When I send me response the servers always respond with EAP-Failure. The
open source Hostapd server complains about a bad TLS mac.

When I use Ethereal to compare what I send with what Windows Zero Conf (WZC)
AND WPA_Supplicant send there are noticable differences as follows:

1) WZC sends one EAP packet containing one TLS application data packet with
a byte payload.
2) WPA_Supplicant sends one EAP packet which contains two TLS application
data packets, one 38 bytes long, the second being 48 bytes long.
3) My client sends one EAP packet with one TLS application data packet with
a 66 byte payload which contains the 49 byte CHAP response packet (RFC 2759,
para 4).

My question is this:

The MSCHAP response to the server challenge is the 49 byte structure defined
in RFC 2759, para 4. Why then do both WZC and WPA_Supplicant respond to the
MSCHAPV2 server challenge message with an initial TLS Applciation data
packet that is smaller than the 49 byte client response message?

Jim Howard
jim [at] grayraven [dot] com

Jim maybe ask ( I believe you have their e-mail ) that from
open source WPA_Supplicant program guys , btw which one do you use ?
Arkady

"Jim Howard" <(E-Mail Removed)> wrote in message
news:uPIIIu$(E-Mail Removed)...
> Howdy,
>
> I am writing an 802.1x wireless client program that will (I hope) support
> authentication using PEAP/MSCHAPV2 authentication. I have a question, but
> first please let me tell you where I am, then I will state my question:
>
> I have a complete phase 1 of PEAP and have a working TLS tunnel. Through
> this tunnel I receive what I'm pretty sure is the MSCHAPV2 eight byte
> server challenge.
>
> I then construct the 49 byte client response per the MSCHAP specficiation.
> I think my basic crypto code is correct, because when I run the test
> vectors that are included with the open source WPA_Supplicant program I
> get the same results.
>
> When I send me response the servers always respond with EAP-Failure. The
> open source Hostapd server complains about a bad TLS mac.
>
> When I use Ethereal to compare what I send with what Windows Zero Conf
> (WZC) AND WPA_Supplicant send there are noticable differences as follows:
>
> 1) WZC sends one EAP packet containing one TLS application data packet
> with a byte payload.
> 2) WPA_Supplicant sends one EAP packet which contains two TLS application
> data packets, one 38 bytes long, the second being 48 bytes long.
> 3) My client sends one EAP packet with one TLS application data packet
> with a 66 byte payload which contains the 49 byte CHAP response packet
> (RFC 2759, para 4).
>
> My question is this:
>
> The MSCHAP response to the server challenge is the 49 byte structure
> defined in RFC 2759, para 4. Why then do both WZC and WPA_Supplicant
> respond to the MSCHAPV2 server challenge message with an initial TLS
> Applciation data packet that is smaller than the 49 byte client response
> message?
>
> Jim Howard
> jim [at] grayraven [dot] com
>
>

I've posted several questions on the hostapd/wpa_supplicant mailing list,
but never get an answer.

I figured since MSCHAP is a Microsoft protocol, someone on the Ms newsgroups
might be familar with implementing this protocol.

I'm writing my own client for a special purpose application, and I use
windows zero conf and wpa_supplicant as role models.

thanks

Jim



"Arkady Frenkel" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Jim maybe ask ( I believe you have their e-mail ) that from
> open source WPA_Supplicant program guys , btw which one do you use ?
> Arkady
>
> "Jim Howard" <(E-Mail Removed)> wrote in message
> news:uPIIIu$(E-Mail Removed)...
>> Howdy,
>>
>> I am writing an 802.1x wireless client program that will (I hope) support
>> authentication using PEAP/MSCHAPV2 authentication. I have a question, but
>> first please let me tell you where I am, then I will state my question:
>>
>> I have a complete phase 1 of PEAP and have a working TLS tunnel. Through
>> this tunnel I receive what I'm pretty sure is the MSCHAPV2 eight byte
>> server challenge.
>>
>> I then construct the 49 byte client response per the MSCHAP
>> specficiation. I think my basic crypto code is correct, because when I
>> run the test vectors that are included with the open source
>> WPA_Supplicant program I get the same results.
>>
>> When I send me response the servers always respond with EAP-Failure. The
>> open source Hostapd server complains about a bad TLS mac.
>>
>> When I use Ethereal to compare what I send with what Windows Zero Conf
>> (WZC) AND WPA_Supplicant send there are noticable differences as follows:
>>
>> 1) WZC sends one EAP packet containing one TLS application data packet
>> with a byte payload.
>> 2) WPA_Supplicant sends one EAP packet which contains two TLS
>> application data packets, one 38 bytes long, the second being 48 bytes
>> long.
>> 3) My client sends one EAP packet with one TLS application data packet
>> with a 66 byte payload which contains the 49 byte CHAP response packet
>> (RFC 2759, para 4).
>>
>> My question is this:
>>
>> The MSCHAP response to the server challenge is the 49 byte structure
>> defined in RFC 2759, para 4. Why then do both WZC and WPA_Supplicant
>> respond to the MSCHAPV2 server challenge message with an initial TLS
>> Applciation data packet that is smaller than the 49 byte client response
>> message?
>>
>> Jim Howard
>> jim [at] grayraven [dot] com
>>
>>
>
>

Jim I can only advice to check open source ( linux ) how it works with
RADIUS
Arkady

"Jim Howard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I've posted several questions on the hostapd/wpa_supplicant mailing list,
> but never get an answer.
>
> I figured since MSCHAP is a Microsoft protocol, someone on the Ms
> newsgroups might be familar with implementing this protocol.
>
> I'm writing my own client for a special purpose application, and I use
> windows zero conf and wpa_supplicant as role models.
>
> thanks
>
> Jim
>
>
>
> "Arkady Frenkel" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Jim maybe ask ( I believe you have their e-mail ) that from
>> open source WPA_Supplicant program guys , btw which one do you use ?
>> Arkady
>>
>> "Jim Howard" <(E-Mail Removed)> wrote in message
>> news:uPIIIu$(E-Mail Removed)...
>>> Howdy,
>>>
>>> I am writing an 802.1x wireless client program that will (I hope)
>>> support authentication using PEAP/MSCHAPV2 authentication. I have a
>>> question, but first please let me tell you where I am, then I will state
>>> my question:
>>>
>>> I have a complete phase 1 of PEAP and have a working TLS tunnel.
>>> Through this tunnel I receive what I'm pretty sure is the MSCHAPV2 eight
>>> byte server challenge.
>>>
>>> I then construct the 49 byte client response per the MSCHAP
>>> specficiation. I think my basic crypto code is correct, because when I
>>> run the test vectors that are included with the open source
>>> WPA_Supplicant program I get the same results.
>>>
>>> When I send me response the servers always respond with EAP-Failure.
>>> The open source Hostapd server complains about a bad TLS mac.
>>>
>>> When I use Ethereal to compare what I send with what Windows Zero Conf
>>> (WZC) AND WPA_Supplicant send there are noticable differences as
>>> follows:
>>>
>>> 1) WZC sends one EAP packet containing one TLS application data packet
>>> with a byte payload.
>>> 2) WPA_Supplicant sends one EAP packet which contains two TLS
>>> application data packets, one 38 bytes long, the second being 48 bytes
>>> long.
>>> 3) My client sends one EAP packet with one TLS application data packet
>>> with a 66 byte payload which contains the 49 byte CHAP response packet
>>> (RFC 2759, para 4).
>>>
>>> My question is this:
>>>
>>> The MSCHAP response to the server challenge is the 49 byte structure
>>> defined in RFC 2759, para 4. Why then do both WZC and WPA_Supplicant
>>> respond to the MSCHAPV2 server challenge message with an initial TLS
>>> Applciation data packet that is smaller than the 49 byte client response
>>> message?
>>>
>>> Jim Howard
>>> jim [at] grayraven [dot] com
>>>
>>>
>>
>>
>
>

"Arkady Frenkel" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Jim I can only advice to check open source ( linux ) how it works with
> RADIUS
> Arkady
>

Arkady, thanks. I am doing that.

The core problem I have is that of the blind men and the elephant. While we
have specs for each part of the process, EAP, PEAP, TLS, MSCHAP (V0,V1,V2),
WPA, RADIUS and others, it's hard to find documentation that describes
exactly how all these different specs interact down where the rubber meets
the road.

I am making some progress. When (think positive!) I have the whole
peap/mschapv2/wpa thing figured out I'll come back and answer my own
question.

But if I ever meet the programmer who coded Windows Zero Conf, I'd buy beer
for as long as he or she would talk about implementation details!


Jim

Some details of WZC you can take from Windows CE , look at Platform Builder
source directories DRIVERS\NETSAMP\WZCTOOL and DRIVERS\NETUI for that too.
About beer , I have some doubts because they sign NDA
Arkady

"Jim Howard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Arkady Frenkel" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Jim I can only advice to check open source ( linux ) how it works with
>> RADIUS
>> Arkady
>>
>
> Arkady, thanks. I am doing that.
>
> The core problem I have is that of the blind men and the elephant. While
> we have specs for each part of the process, EAP, PEAP, TLS, MSCHAP
> (V0,V1,V2), WPA, RADIUS and others, it's hard to find documentation that
> describes exactly how all these different specs interact down where the
> rubber meets the road.
>
> I am making some progress. When (think positive!) I have the whole
> peap/mschapv2/wpa thing figured out I'll come back and answer my own
> question.
>
> But if I ever meet the programmer who coded Windows Zero Conf, I'd buy
> beer for as long as he or she would talk about implementation details!
>
>
> Jim
>

Forgot to mention , that WPA2 enhancements issued after XP SP2 ( the same
time CE 5 ) so I'm afraid that you'll not see them in PB but WEP/WPA do have
shown there
Arkady

"Arkady Frenkel" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Some details of WZC you can take from Windows CE , look at Platform
> Builder source directories DRIVERS\NETSAMP\WZCTOOL and DRIVERS\NETUI for
> that too.
> About beer , I have some doubts because they sign NDA
> Arkady
>
> "Jim Howard" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>
>> "Arkady Frenkel" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Jim I can only advice to check open source ( linux ) how it works with
>>> RADIUS
>>> Arkady
>>>
>>
>> Arkady, thanks. I am doing that.
>>
>> The core problem I have is that of the blind men and the elephant. While
>> we have specs for each part of the process, EAP, PEAP, TLS, MSCHAP
>> (V0,V1,V2), WPA, RADIUS and others, it's hard to find documentation that
>> describes exactly how all these different specs interact down where the
>> rubber meets the road.
>>
>> I am making some progress. When (think positive!) I have the whole
>> peap/mschapv2/wpa thing figured out I'll come back and answer my own
>> question.
>>
>> But if I ever meet the programmer who coded Windows Zero Conf, I'd buy
>> beer for as long as he or she would talk about implementation details!
>>
>>
>> Jim
>>
>
>