Hi Vidya,
just a quick comment.
Narayanan, Vidya wrote:
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?
You must be kidding.
We worked on this several months within a design team. The design team
concluded that a new EAP method is the right direction. Then, the result
of the design team was confirmed by working group a long time ago.
Now, in WGLC you raise your voice although you and Lakshminath actively
participate in the working group (with Lakshminath even being a design
team member).
I will address your comments after I recovered from a flu.
Ciao
Hannes
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
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
