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

On Tue, Aug 05, 2008 at 12:36:21PM -0700, Joseph Salowey (jsalowey) wrote:
> 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. 

Hmm.. I don't know whether I would really see much point in client-side
DoS protection for EAP-GPSK, so that part in 12.9 does not matter to me
much. As far as peer implementations are concerned, I don't see any
significant difference in storing (RAND_Peer,CSuite_Sel,RAND_Server) vs.
(RAND_Peer,CSuite_Sel) between GPSK-2 and GPSK-3.

> 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."

I don't see real value in RAND_Server being included in GPSK-3, so in
that sense I'm fine with this.

> 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."  

s/Csuite_Sel/CSuite/Sel/

Doing this per-server sounds restricting to me and would mandate that
there is never going to be two simultaneous EAP-GPSK authentication
sessions going on. Do we really care about storage requirements for 32
octets of extra state when the peer would need to store some state
anyway (38 octets vs. 70 octets)? I would rather optimize the packet
sizes be removing 32 octets from GPSK-3..

Anyway, if there was consensus on this being something worth doing, I
won't be against the text changes you propose here. I think the protocol
would work either way and at this point, my main preference is just to
get EAP-GPSK published rather sooner than later ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu