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

From: Jouni Malinen <[email-masked]>
Date: Sat, 2 Aug 2008 10:54:00 +0300

On Tue, Jul 29, 2008 at 12:28:02PM -0400, Charles Clancy wrote:

> This state-minimization approach was proposed by the Stanford security 
> review.  In earlier versions of the draft, CSuite_Sel and RAND_Server were 
> not included in GPSK-3, and were not verified.  I'm not sure why the 
> language you referenced below got updated after they were added to GPSK-3.
>
> All -- Does anyone in the WG object to this change?

I would assume the validation was removed in order to allow peer
implementation to not store RAND_Server after having derived the keys
and sent GPSK-2. Peer will need to know CSuite_Sel for verifying the MIC
in GPSK-3 and I would rather not rely on the value sent in GPSK-3 to do
this, so that part of the change would not reduce any space in the peer
implementation. Anyway, if the values in GPSK-3 are not verified, I
don't see much point including them there.. Consequently, I would prefer
to revert this change of removing validation of RAND_Server and
CSuite_Sel in GPSK-3 and go back to -10 version of that text.

By the way, I just noticed that there seems to be something even more
seriously broken in this paragraph:

   For GPSK-3, a peer MUST silently discard messages where the RAND_Peer
   field does match the value transmitted in GPSK-2.

The "discard where _does_ match" does not sound correct; it should be
_does not_ match. ;-) This has been incorrect since the text was added
in -02.. Clearly this have been too obvious for anyone to notice before
(yes, I must have read that, too, and still, I ended up implementing the
correct "does not" behavior, not the one specified here).

This a text I would actually like to see here:

   For GPSK-3, a peer MUST silently discard messages where the
   RAND_Peer, the RAND_Server, or the CSuite_Sel fields do not match
   those transmitted in GPSK-2.  An EAP peer MUST silently discard any
   packet whose MAC fails.
 
-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 5 Aug 2008 12:36:21 -0700

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

---

From: Jouni Malinen <[email-masked]>
Date: Wed, 6 Aug 2008 12:08:02 +0300

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

>    those transmitted in GPSK-2.  An EAP peer MUST silently discard any

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

>    Csuite_Sel on a per-server basis for servers it knows instead of on a

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 ;-).