Update for Windows XP (KB917021)

Thanks Arie.

This sounds like a must-do upgrade for security reasons.

 

I just read your newsletter re: this update. I went to the windows update page to see if this update had been downloaded automatically.

I could not find it listed in my download history. Last download being October 10.

Thinking that was quite a long time ago, and did I miss some downloads somehow since I have a new computer that may not yet be completely configured, I hunted for a list of downloads and finally found one that did list the last download to be on Ocotber 10.

But, this KB917021 was not listed, and it looks like it was dated around the October 20th. AND, the details say you don't need it if you have Wireless Client Update installed.

How do you know if you have Wireless Client update installed?

I cannot find it in the Add/Remove program list

And, if this is critical, why hasn't it been automatically downloaded?

 

This kind of upgrade would not be pushed automaticly by Windows Update. If you do a Manual, Custom Windows Update the upgrade should appear on the list, but not as "critical. "

"How do you know if you have the Wireless Client Update installed?

So, if you have KB893357 installed (the Wireless Client Upgrade), and Service Pack 2, you do not need this upgrade.

 

That is a more sensible interpretation.
Thanks Tony T.

 

I too am happier with XP than third-party wireless connectoids.

Post-VISTA there will be several important Wifi products from Microsoft. The Live Wifi client in Beta now is terrific.

 

WZC (or is it WAC now?) and user's credentials on hardware tokens.

Yes, KB917021 is very usefull an welcome update.

Does anybody here know if there will be the last important enhancement for the WZC - the introduction of support for the user certificates on hardware tokens?

I've been struggling with the Aladdin's eToken PRO - WZC currently ignores any non-software storages... The Aladdin's developers could not help with this. I have to use my WPA2-Enterprize with the cert in the registry store...

winXP-SP2, Aladdin's RTE v3.65.

Thank you in advance,
Tony.

 

Check the Enable network access control using IEEE 802.1X check box.

For EAP type, select PEAP. Click Properties. The PEAP Properties screen appears. Click Server Certificate authentication at the top.

Currently Generic Token Card is the only second phase EAP type available. Click Properties. The Generic Token Card Properties screen appears. There is a provision for hardware tokens.

 

Nope...

I'm not sure what you describe here.

My WPA2-Enterprize is EAP-TLS, but I did try all other settings. And I did specifically select the Use my smart card option - does not work. I see a momentarily appearing baloon and then the message of "not finding the smart card ". (I do have the "Generic smart card support" update installed)

 

EAP-TLS authentication with smart cards, while supported for dial-up and VPN connections, is not supported for wireless connections.

 

Strange.

Is it the intentional omission?
Any plans to implement it?

 

It was intentional.
There are no current implementation plans.

The reason for this is that Microsoft is a very standards based developer. As far as their official position it would be that they make every effort to be inclusive of standards-based security features. (I know of no other company that offers as wide a range of wireless supplicants as found in XP SP2).

But there are no standards for hardware tokens in EAP-TLS.

For example in Alladin a proprietary means is to read the key. Standards Working Groups believe being able to display the private key modulus and export it is not the same; in the Aladdin case it can be displayed but not exported. What is being displayed is not sufficient to sign a message or re-import the key back onto a token.

There are number of different token technologies. Token technology that will allow a key pair to be generated on the token rarely gives you the ability to export the key. If the public/private key pair is generated on the token, not exportable, and the token is lost, the only thing that protects the key is the pin/password that secures opening the key store on the token.

Until a standard is achieved, Microsoft will insist it would be up to the Manufacturer (Alladin in your case) to supply the necessary supplicant.

Microsoft does make this much easier for a developer under Vista. The new network stack has deliberate hooks for custom supplicants.

 

That is very regretfull if true.

Oh, please, don't!

And there should not be any.
It is not about tokens. EAP-TLS is about any certificate-based authentication.
It, as such, should not worry about where actually a cert is stored.

I'm I right on reading this as the demand for the private key to be exportable|retrievable from a hardware token?!
The message signing goes on in the token's hardware, there is no legitimate reason to demand to export the signing key out! (Other that the escrow policy, it that case one may generate *.p12 file and import it into a token while storing the file safely. This all defeats the hardware tokens idea - and I would never let my private key to lay somewhere else.)

This is the Good Thing (tm) in my eyes. The whole idea of hardware tokens is about inretrievability of a private key.

What is wrong here?
I see it 100% correctly done - the token itself demands the PIN to access it and there is the RSA-key passphraze, protecting the key.

To my eyes the fact that WZC does not try the the certs in tokens is just a silly mistake.
The actual hardware-based cert is clearly visible in user's cert-store, it is quite usable for it's intended usages (if allowed by it's extentions) - I have keys to sign|decode my e-mail. I have certs to do my VPN. All in my token. The only service that ignores hardware storage here - is WZC.
I do hope that winXP-SP3 will finally address this issue.

 

Thanks, Tony.
I have no problems with WiFi, WPA2-Enterprize, EAP-TLS and WZC - as long as I've given up on insisting in WZC to use my cert stored in the token. WZC and the same cert in the software storage works just fine.
My check-boxes are set exactly as shown in those documents above.

All I want|wish is WZC to use CryptoAPI as all other win32 programs do.

If it would try something similar to "cryptoapicert "THUMB=xx xx xx... "" - then all will work automagically - the Aladdin's (in my case of using their RTE) top-up would appear asking for the token's PIN and then another - asking for the RSA-key's passphraze.

RE Bill Castner's statement about lack of standartization for tokens in EAP-TLS:
No S/MIME RFC|document ever mentions hardware tokens either, Aladdin's eToken PRO in particular. But somehow all decent PKCS#11-aware e-mail clients are able to use hardware tokens just fine... What do they do wrong?! Do they violate S/MIME standards?!

RE "lost|stolen" status of a token - this is completely irrelevant to EAP-TLS standards as well. Besides, a cert on the software storage is far more vulnerable to all sorts of abuse...

I hope someone responsible from MS is reading this site too. Please relay my plea for making the WZC fully PKCS#11-aware service.

 

Thanks for the explanation re: how to find if the updates are installed on my computer.

I do have the "hotfix" KB893357, but do NOT have the last update 917021. In reading the KB article on the Microsoft page, I understand that this update does offer additional security in addition to that in 893357 update.

But, didn't someone say that the 917021 update was not needed if you had 893357?

Or am I completely confused?

 

You are.
It is exactly the other way around: the 893357 update was not needed if you had 917021.
Actually, the KB917021 is the security fix - it prevents the vulnerabilities, if you read the description properly...

 

Thanks for setting me straight. I did read the article and the KB instructions, but did not understand, so as you say, I did not read it correctly and I was most definitely confused.

Will now download the correct security fix.