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:[EMAIL PROTECTED] > Sent: 29 July, 2008 14:42 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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 > > > [EMAIL PROTECTED] 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
