Does wpa supplicant version 0.6.4 support Windows, Server2008NAP IEEE802.1X Enforcement ?

[James Woo]

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 2 Oct 2008 19:53:47 +0300
> From: Jouni Malinen <j at w1.fi>
> Subject: Re: Does wpa supplicant version 0.6.4 support Windows
> 	Server2008NAP IEEE802.1X Enforcement ?
> To: hostap at lists.shmoo.com
> Message-ID: <20081002165346.GD4840 at jm.kir.nu>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Oct 01, 2008 at 04:39:14PM -0700, James Woo wrote:
>
>   
>> I got thru if I use Jouni's SoH data.
>>     
>
> I added generation of all the mandatory fields into wpa_supplicant (in
> git development branch 0.6.x). It would be interesting to see whether
> you'll get the same results with that one. The vendor specific
> attributes in SSoH are more or less the same, but there is no
> SoHReportEntry. Anyway, there should be zero or more of those, so zero
> sounds like the easiest option here.. ;-)
>
>   
>> But it still failed authentication with the following error messages:
>> "EAP-TLV: Unsupported TLV Type 7" and
>>     
>
> That is most likely fine. TLV type 7 is vendor specific TLV and the
> vendor id seems to indicate this is some Microsoft data. I would assume
> this can be safely ignored since it does not have mandatory bit set. If
> not, one would hope this is documented somewhere.
>   
Tragically, you can ignored TLV type 7 and can received a successful 
authentication.
But you won't know whether you're compliant or not. That's the tragedy 
of NAP.
It relies on a honest NAP client for NAP enforcement.
With the test data, it returns a quarantine state of 1 (full access for 
network connectivity).
However, there's something wrong with the test data.

SoHReportEntry:
  System-Health-Id: 00 02 00 04
    Value: Health ID: IANA SMI Code: 00 01 37   Id: 80
  Vendor: 00 07 00 08 00 01 37 80 02 00 00 00
  Vendor: 00 07 00 08 00 01 37 80 00 00 01 05
                                  ^^^^^^^^^^^
According to WSHA and WSHV spec, Section 2.2.5, Windows XP WSHA should be 0x50001
What's interesting is that if it is changed to 0x50001, the quarantine state returns 0xb 
(Restricted access, remediation required).

TLV_Type07 is also missing from the test data. It contains the Antivirus_HealthClassID.
This is a violation of the spec. Section 2.2.1 says, "All of the values MUST be present, 
unless otherwise noted. The values MUST be in this order". It's weird.

I've tested the latest tncc.c from the snapshot. It returns quarantine state of 0xb
(Restricted access, remediation required). I don't think you can exclude the SOH from
the SOH request because w/o it the WSHV can't determine whether you're compliant or not.


>> "EAP-PEAP: Invalid Compound_MAC in cryptobinding TLV"
>>     
>
> This is unfortunate. I haven't seen problems with Compound_MAC when
> testing my server code with Windows XP SP3 supplicant. Since
> wpa_supplicant works with that server code, I would have hoped this
> would also mean it works with Windows Server. I'm not sure what could be
> causing this here. The test runs I've done with hostapd as the server
> and Windows XP as the client seem to go through the exact same sequence
> and Compound_MAC is matching there. Have you tested crypto binding
> without SoH/NAP?
>   
I can get successful authentication by commenting by the crypto binding 
TLV handler.