Hi Hannes,
I hope you recover quickly from the flu. Please see inline for some notes:
Hannes Tschofenig wrote:
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.
Why do you think that? While we don't (need to) do this often, there is
nothing wrong in asking ourselves why a certain protocol is needed or
not before we forward it out of the WG. In the MSEC WG (several years
ago), we considered the question of why we need to publish yet another
group key management protocol, a few times. When MIKEY was sent to the
IESG, there was the question of why we need one more DH-based key
management protocol. It doesn't hurt to ask ourselves that question.
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).
Let's see: I haven't (yet) said anything about not forwarding this to
the AD. I sent in my comments and others might explain why one or more
of them are invalid. That's where it stands.
I did consider the question that Vidya poses as to why we need GPSK and
why can't we use EAP-TLS-PSK instead. I disagree with her opinion at
the moment: assuming all else goes well with GPSK, I am ok with
publishing it. I am not sure about recommending it to anyone (other
SDOs for e.g.) just yet. There is a question in the back of my mind as
to if/when EAP-TLS-PSK is specified and if/when a TLS extension to carry
"additional data" is specified, why would anyone use GPSK and not
EAP-TLS-PSK.
In the meanwhile, if Vidya or anyone else raises the question on why are
we doing this, we have a responsibility to answer.
My answer is EAP-TLS-PSK is not there yet and there is no way to carry
"additional data" in EAP-TLS-* yet.
regards,
Lakshminath
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
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
