Hi Hannes, Lakshminath, Some responses inline. > -----Original Message----- > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 07, 2007 8:44 AM > To: Hannes Tschofenig > Cc: Narayanan, Vidya; [email protected] > Subject: Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03 > > 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. >
I'm sorry that I'm raising this question at LC, rather than before, but, I figured it was better late than never. We all have finite amounts of time and we try to follow a bunch of work and often find ourselves waking up during LCs, sometimes later even. If someone asked me the advantage of doing GPSK over TLS-PSK, I really don't have an answer from the document as of now. > > > > 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 cannot speak for Lakshminath and he has responded for himself already. I have to say that I haven't closely followed the design team activities. An LC review of the document is what really triggered this. > 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. > Well, defining and implementing carrying of "additional data" in TLS is IMHO much simpler than defining and implementing a new method. So, if "additional data" is your only justification, that seems really weak to me. Regards, Vidya ps: Hannes, I wish you recover soon and look forward to discussing more details later. > 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
