Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 15 and is now closed.
Jari Arkko Yes
Comment (2008-11-05 for -)
Good work, guys! The specification is in very good shape, and is going to be useful for the EAP community. I did find two minor sources of confusion, and if you can fix these it would be nice: > [A..B] extracts the string of octets starting with octet A finishing > with octet B from the output of the KDF function. Presumably counting starts from 0? > EAP-GPSK provides protection against reflection attacks in case of an > extended authentication because the messages are constructed in a > different fashion. What is meant by "extended authentication" in this case? (Also, a reference to the definition of a reflection attack would be nice.) (Note: I am listed as a contributor in the document, but I chose to ballot for the document anyway, given that my contribution in the design team was more about starting the team than actual technical work.)
( Pasi Eronen ) (was No Objection, Discuss, Yes) Yes
( Ross Callon ) No Objection
( Lisa Dusseault ) No Objection
( Lars Eggert ) No Objection
( Russ Housley ) No Objection
( Chris Newman ) No Objection
Comment (2008-11-05 for -)
It would be helpful to me if there was a discussion of how EAP-GPSK relates to EAP-TLS+TLS-PSK. Presumably the former is a bit lighter weight, while the latter provides optional privacy, is likely to have more code review and is more likely to permit storage of the key in a PKCS#11 module. Can general advice be given? Perhaps EAP-GPSK is preferred by default? Or perhaps EAP-TLS explicitly requires certificates and thus a new EAP code would be needed to use EAP-TLS-PSK?
( Jon Peterson ) No Objection
( Tim Polk ) (was Discuss, No Objection) No Objection
Comment (2008-11-04 for -)
(1) The notation KDF_X(Y) is defined in Section 2 but is never used. KDF-X(Y,Z) [A..B] is defined in Section 4, and is used extensively. This is a bit confusing, since the differences are minor, so please delete the definition of KDF_X(Y) in Section 2. (2) The definition for MK is given as "Master Key between the peer and the EAP server" which sounds very similar to the PSK. Consider expanding this definition to indicate that the MK is derived from the PSK, and is session specific. Perhaps something like MK: A session specific Master Key derived from the PSK by the peer and EAP server ... (3) In Section 3, third paragraph from the end of the section describes the processing of GPSK-2 by the server as follows: "The EAP server verifies the received Message Authentication Code" This is necessary but not sufficient. In addition to the MAC, the EAP server needs to verify that the parameters it included in GPSK-1 were correctly repeated in GPSK-2. (Otherwise, there is no value in repeating them!) This would be consistent with the packet processing rules in section 10. Similar requirements (to verify the server and selected ciphersuite) extends to processing GPSK-3 by the peer and should be specified in the following paragraph. (4) Section 10: When processing GPSK-3, the processing rules do not involve ID_Server. Shouldn't the peer verify the ID_Server is the same as in GPSK-1 and GPSK-2? And if ID_Server does not match, what are the processing rules?