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

Charles,

Thanks for the update! There's one change I'm slightly worried 
about:

Version -10:
   For GPSK-3, a peer MUST silently discard messages where the
   RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match 
   those transmitted in GPSK-2.

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

I guess the security analysis of GPSK was performed assuming
the peer does check RAND_Server and CSuite_Sel? 

While I can't come up with any attack even if this check is
omitted (e.g., RAND_Server and CSuite_Sel are still included 
in MK derivation), is the whole WG comfortable with this change?
(I didn't see any discussion about this topic yet.)

Best regards,
Pasi

> -----Original Message-----
> From: ext Charles Clancy [mailto:tcc@umd.edu] 
> Sent: 29 July, 2008 14:42
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: Hannes.Tschofenig@gmx.net; clancy@cs.umd.edu; emu@ietf.org
> Subject: Re: Review of draft-ietf-emu-eap-gpsk-08 (1st round 
> of comments)
> 
> Pasi,
> 
> I've submitted an update that addresses the ASCII text garbling, PL 
> encoding, packet validation inconsistencies, and IANA policies.  All 
> that remains is the key/MAC-length issue.
> 
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
> 
> 
> Pasi.Eronen@nokia.com wrote:
> > Hannes Tschofenig wrote:
> > 
> >>> As Dan Harkins already pointed out, NIST 800-38B does define CMAC 
> >>> for 256-bit AES, with 256-bit key and 128-bit output.
> >>>
> >>> So hardcoding this assumption in EAP-GPSK seems to limit 
> the future
> >>> algorithm agility somewhat -- is the WG sure this is an acceptable
> >>> limitation?
> >>>
> >>> (If this limitation is kept, I'd suggest mentioning in Section 2
> >>> that "KS" is not only the key size, but also MAC output length.)
> >> This seems to require a separate discussion on the list.
> > 
> > Ok -- please let me know once you think the discussion has
> > concluded.
> > 
> >>> The text (Section 5) should probably say something about non-ASCII
> >>> characters, especially since NAIs can contain them (and IETF
> >>> policies usually require dealing with non-ASCII in strings handled
> >>> by ordinary users -- RFC4306/4279 are probably mostly for admins).
> >>>
> >>> Maybe "SHOULD support non-ASCII", with pointer to detailed 
> >>> instructions in Section 2.4 of RFC 4282?
> >> Fixed.
> > 
> > It seems this update got garbled somehow -- at least I have some
> > difficulties in parsing the new text:
> > 
> >    Thus the management interface SHOULD support non-ASCII to allow
> >    entering values for the ID_Peer and ID_Server as ASCII strings up
> >    to 254 octets in length.
> > 
> >>> S4, how is PL encoded when input to KDF? (1 octet, 2 octets?)
> >>    
> >> 2 octets.
> > 
> > The text in Section 4 should say so.
> > 
> >>> S12.9: the text about minimal state (only RAND_Peer) seems
> >>> inconsistent with S10, which requires discarding GPSK-3 if the
> >>> RAND_Server and CSuite_Sel fields are not the same as in GPSK-2.  
> >>> To make that comparison, it seems you need to store the 
> values after
> >>> sending GPSK-2?
> >>   
> >> I added text on this issue. I am not fully sure whether it resolves
> >> the aspect entirely though.
> > 
> > Not really -- the text in Section 12.9 seems to say that doing
> > the comparison (of RAND_Server and CSuite_Sel) can be omitted,
> > but it's a MUST in Section 10. These two sections need to be
> > consistent.
> >  
> >>> >From idnits: 
> >>> Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
> >> Ok.
> > 
> > The names of the pre-defined IANA policies were also 
> slightly changed,
> > so Section 13 needs some small updates.
> > 
> > Best regards,
> > Pasi
> 
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu