Charles Clancy wrote: > See comments inline. An updated draft will be released shortly. > Also note that the new draft addresses Dan's comments about > resistance to dictionary attack.
Thanks for the update! I have some additional comments (see below), but they should be easy to address. > > S4, "EAP_Method_Type refers to the integer value of the IANA > > allocated EAP Type code", "...to the EAP type code (1 byte), > > specified in Section XX"? > > I don't think it's ever been clear how to reference the IANA > allocated EAP type code in an I-D before it's been allocated. These > are things that would be fixed by the RFC Editor or in AUTH48, once > IANA has allocated the type code. For clarity, I'd still suggest adding the "(1 octet)" part (although someone reading RFC 3748 will of course figure out that it's 1 octet). > > S6 and elsewhere: Several places in the document assume that KS > > (key size of the ciphersuite) is always the same as the MAC output > > length. This would make it difficult to define ciphersuites based > > on e.g. AES-CMAC-256. If this restriction is intentional (and WG > > is happy with it), at the very least it needs to be emphasized > > much more. > > I'm not sure what AES-CMAC-256 means. RFC 4493 defines CMAC > specifically for 128 length AES, so if you wanted to something > involving 256, you'd need to define exactly what AES-CMAC-256 was, > and I imagine it would have a 256-bit input and a 256-bit output. > Regardless, I added a statement in the key derivation section saying > the input and output lengths of your ciphersuite must be equal. 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.) > > S5 and S8.2 are not consistent about ciphersuite formatting (is > > enterprise number 3 or 4 octets; if you're not sure, suggest > > doing what RFC3748 did) > > Fixed (should be 4). Figure 3 in S6 still assumes it's 3. > > S8.4, text and bit diagram are not consistent about whether > > enterprise code is 3 or 4 bytes > > Text consistent with length 4 enterprise code. The 1st figure (now in S9.4) still shows 3 octets; so does the text at end of S9.4, and IANA considerations text for PData/Specifier. > > S9, "If the MAC validation fails, the server MUST transmit a > > GPSK-Fail message specifying "Authentication Failure" and discard > > the received packet." Not quite sure what "discard the received > > packet" here exactly means in the context of EAP state machine (If > > the server sends a reply, it's not discarding the packet as such). > > Fixed. It seems this text was not changed at all? > > Interoperability requires the ability to enter same PSK in > > both client and server. See e.g. RFC4306 S2.15 and RFC4279 S5.4 > > for examples of management interface requirements. > > Added. 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? Addtional comments: S2, "PL": would help reading if it said PL must be >= KS (it's said in S6, but this assumption is already needed in S4). S3, should also mention GPSK-Fail and GPSK-Protected-Fail messages for completeness (in additino to GPSK-1...4). S4, how is PL encoded when input to KDF? (1 octet, 2 octets?) S9.3, "from the ID_Client length" -> "from the ID_Peer length" S11, GPSK-3 and GPSK-Fail are distinct message Op-Codes, so showing e.g. "EAP-Request/GPSK-3 (GPSK-Fail (PSK Not Found or Authentication Failure))" is confusing. Should be just "EAP-Request/GPSK-Fail ...". S12.1, the references to sections 11.* should be to 12.* (and some of the subsection numbers don't match; e.g. channel binding is .13, not .12). 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? >From idnits: Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
