Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method
RFC 5433

Note: This ballot was opened for revision 17 and is now closed.

(Jari Arkko) Yes

Comment (2008-11-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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

(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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

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 ...

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.

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?

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection