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
