On Wed, 2002-10-02 at 15:17, Lars Viklund wrote: > On Wed, 2002-10-02 at 09:24, Pat Calhoun wrote: > > > send the supplicant an EAPOL-Key message with an empty Key field, which > > > means use the specified number of bits from the MS-MPPE-Send-Key as the > > > key-mapping key. > > > > check... unfortunately, this doesn't appear to work. > > Do you mean "not work" in the sense that Win XP doesn't accept such > EAPOL-Key messages that you send to it?
well, XP isn't quite nice enough to actually *tell* me that it doesn't like my EAPOL-Key message... but I know that manually decoding the packets it sends using what I believe is the key (from the MPPE-Send-Key attribute) fails the checksum process... so it's using something other than what's in the MPPE-Send-Key (or perhaps a different set of bits than I am). > > > However, I found > > going through the various revisions of the congdon draft that the > > signature has changed over time, and this may be what's biting me. I > > found that in -17 of the draft, the signature doesn't cover the EAPOL > > header, while -20 it does. I suspect what's going on is that they are > > trying to play catch up with the work in .1aa, but it would be really > > nice if there were a draft that showed how 802.1X worked :( > > > > Any ideas how XP behaves? > > No, but I seem to remember that the Cisco 340 sends EAPOL-Key with an > empty Key field (at least if 104-bit keys are used) and that this works > with Win XP, so it should be possible to figure out the details. Right. Sending a unicast key is really unnecessary (and in some cases even not recommended). So sending an EAPOL-Key packet with the optional key field absent is a message to the supplicant that it should use the key it received during the TLS negotiation. This is what I am trying to do, but XP doesn't seem happy. I suspect that as I mentioned above, I need to find the exact congdon draft that covers 802.1X expected behavior :( PatC - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
