Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st roundof comments)

If we make the change below then we also have to change section 12.9.  I
think this is a bit problematic since at one point we had consensus to
address the issues on client state avoidance raised by folks at
Stanford.  The goal was that the peer could store its nonce on a
per-server basis rather than on a per-message basis.  Since the peer is
only going to have shared secrets for a limited number of servers this
could reduce the amount of state that needed to be kept. 

I don't see the value of matching the RAND_Server on the peer so I would
modify Jouni's text as follows:

   "For GPSK-3, a peer MUST silently discard messages where the
   RAND_Peer or the CSuite_Sel fields do not match
   those transmitted in GPSK-2.  An EAP peer MUST silently discard any
   packet whose MAC fails."

The text for section 12.9 the third paragraph needs to be clarified:

   "The client has to keep state information after receiving the GPSK-1
   message.  To prevent a replay attack, all the client needs to do is
   to ensure that the value of RAND_Peer is consistent between GPSK-2
   and GPSK-3.  Message GPSK-3 contains all the material required to re-
   compute the keying material.  Thus, if a client chooses to implement
   this client-side DoS protection mechanism it may manage RAND_Peer and

   Csuite_Sel on a per-server basis for servers it knows instead of on a
   per-message basis."  

Does this help?  Is there a reason the peer would need to track
RAND_Server?  

Thanks,

Joe 
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu