All, I reviewed the document and unfortunately, don't feel it is ready for publication yet. I will only get into the meta issues here - nits can be addressed later.
Major Comments: --------------- 1. Overall, I'm looking for a compelling reason to have another EAP method and I found none in the document. For instance, all the design goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected payloads can be done as an extension to TLS as well). And, given that EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one design goal of GPSK that cannot be met by other methods? 2. Are the EAP and GPSK headers integrity protected? The SEC_SK construction in various places does not seem to imply so - I don't think that is the intention, as those headers must be integrity protected. 3. The message, GPSK-4, seems to be there since an EAP Response is needed after an EAP Request. However, this seems to lead to a couple of things - a) a potentially empty message sent with a MAC (what is the MAC calculated on?), b) having the client to reflect back a failure message in the event of a failure. I think if the EAP and GPSK headers are protected with a MAC, we should be okay with this. 4. Is there a reference to GKDF? I'm wondering why we are advocating the use of hash functions as KDFs instead of HMACs. I have more questions on the derivation of MK and other keys, but, I'll wait for the clarification on GKDF before I ask those. 5. Is the PK always derived? Having a PK for the case where the encryption algorithm is NULL (in Ciphersuite 2, for instance), doesn't seem to be of any value. This actually brings up a question on the need to define the KDFs the way this document has. For instance, the 2*KS value seems to be there to determine the KDF length, with the assumption that the encryption and integrity key lengths required for the ciphersuites are equal. A better construction seems to be along the lines of IKEv2's prf+, that can produce keys of variable lengths. Was this considered and if so, why was the GKDF construction as defined seen as a better way to go? Not-so-major Comments: 6. The document seems to re-naming some EAP terminology. I don't think there is a need to do that. 7. Section 8 says "Any packet that cannot be parsed by the EAP client or the EAP server MUST be silently discarded" - this seems to be defining EAP behavior. In other words, if the packet cannot even be parsed as a GPSK packet, EAP will be discarding that packet, not GPSK. Thanks, Vidya _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
