Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method
RFC 5433
Yes
No Objection
Note: This ballot was opened for revision 17 and is now closed.
Lars Eggert No Objection
(Jari Arkko; former steering group member) Yes
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; former steering group member) (was No Objection, Discuss, Yes) Yes
(Chris Newman; former steering group member) No Objection
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?
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) (was Discuss, No Objection) No Objection
(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?