PMKID caching is possble with out preauthentication??

[Bryan Kadzban]

Anjaneyulu Jagarlamudi wrote:
> Iam implementing only PSK,

Then I'm not sure, but I don't believe there's any need for PMKID caching.

In PSK mode, I'm pretty sure that the (hex) pre-shared key *is* the PMK
for all clients.  Assuming that's actually true, then there's no need to
cache the PMK for each AP for use when roaming, because all the APs will
have to use the same PSK, so they'll therefore have to use the same PMK.
And the supplicant already knows this PMK, so it shouldn't have to cache
it.

(It's also possible that PMKID caching can cut down on the 4-way
handshakes; I kinda doubt it though.  The supplicant would still have to
prove it was actually there, not replaying packets, and would still have
to prove that it knew the current PMK; this is what the 4-way handshake
proves.)

I believe the reason PMKID caching exists is so the supplicant can
authenticate through a second AP (using whatever EAP method) while still
connected to its current AP.  Then, it'll store the results of the
authentication (the PMK) along with the PMKID, in a table somewhere.  So
when it roams to that second AP, it'll look up the PMKID/PMK, and just
use that in a 4-way handshake, instead of going through the entire EAP
authentication process.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20051203/ec13c5da/attachment.pgp