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
