Subject: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Mar 2007 18:03:18 -0800

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? 

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-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Mar 2007 12:56:41 +0200

Hi Vidya,

just a quick comment.

> publication yet. I will only get into the meta issues here - nits can be

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 07 Mar 2007 08:44:06 -0800

Hi Hannes,

I hope you recover quickly from the flu.  Please see inline for some notes:

Hannes Tschofenig wrote:
>> Major Comments: ---------------

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.

> participate in the working group (with Lakshminath even being a design 

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 7 Mar 2007 13:21:17 -0800

Hi Hannes, Lakshminath,
Some responses inline.  

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 8:44 AM
> To: Hannes Tschofenig
> Cc: Narayanan, Vidya; [email-masked]
> Subject: Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03
> 
> Hi Hannes,
> 
> >> publication yet. I will only get into the meta issues here 
> - nits can 
> >> be addressed later.
> >> 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. 

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

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

---

From: Jouni Malinen <[email-masked]>
Date: Wed, 7 Mar 2007 19:37:53 -0800

> design goal of GPSK that cannot be met by other methods? 

As far as I can tell, EAP-TLS-PSK would be yet another EAP method in the
same sense as EAP-GPSK, so I don't see EAP-TLS-PSK in any way a better
solution from the view point of not adding a new method.

As far as comparison of EAP-GPSK vs. EAP-TLS-PSK is concerned, one
major part is in EAP-GPSK being much simpler and smaller from
implementation view point. In most cases, extending TLS seems to bring
in a major extra cost of having to modify a TLS library which is not
desirable in many cases. It may mean that the TLS implementation
included in the system would not be suitable and the EAP implementation
would need to bring in another TLS implementation with maintenance and
memory/flash footprint concerns.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 09 Mar 2007 11:56:07 -0800

Hi,

I have a question.  I have some experience with code reuse, but I was 
hacking, err... prototyping.  What is the general sense on using a piece 
of TLS code to do things like EAP-TLS or EAP-TLS and EAP-TLS-PSK?  I ask 
because elsewhere people make the argument that TLS is already there on 
a certain device and so DTLS is an incremental implementation etc.

I hope we don't have a huge thread on it, but I am curious about 
thoughts on reuse.

thanks,
Lakshminath

---

From: Jouni Malinen <[email-masked]>
Date: Fri, 9 Mar 2007 19:10:45 -0800

> a certain device and so DTLS is an incremental implementation etc.

I think the answer is "it depends"..

In many (most?) embedded client designs I've been involved with in one
way or another, TLS library has been one of the key issues due to the
possible overhead (e.g., OpenSSL can add almost 1 MB to the binary). It
would be ideal, to be able to share the same TLS implementation for all
uses on the device to save in size (both flash and RAM).

In addition to size concerns, it would also be quite helpful if the
native TLS implementation with the target platform could be used (if one
is available) to benefit from existing integration with certificate
store and private key access, including UI components. Providing a nice
user experience with another TLS library can get difficult, if not
impossible, in many cases.

That said, it is not always possible to use the native TLS
implementation. For example, one of the most difficult aspects of
EAP-FAST from implementation view point is its requirement for TLS
extensions (ClientHello extension and session ticket). Most existing TLS
libraries do not support this, so whoever is implementing EAP-FAST may
need to modify TLS implementation and this is something, that is often
not feasible for OS/SDK provided implementation. Consequently, EAP-FAST
(or EAP-TLS-PSK for that matter) may end up requiring the EAP
server/peer implementation to include another TLS library.

If whoever is working with EAP method implementation is also in control
of the system TLS library, adding support for TLS extensions is less
likely to be an issue (though, often the person working on EAP method is
not the same as the one working on TLS library, so this adds some extra
overhead, but anyway, still manageable).

If EAP method is being implemented by someone who does not have any
control on the system TLS library, things can get quite difficult.
Convinsing TLS vendors to add some extensions may take time and effort;
especially so, when they may not see much need for the requested
extension as far as the "main uses" of the TLS from their and most of
their customers view points are concerned (HTTPS? IMAPS?, etc.).

I would say that reusing TLS implementations with functionality
specified in TLSv1 (i.e., without any extensions) is fine in many cases
since most TLS libraries include all the needed functionality. However,
anything new (as in anything brought in during last few years) is going
to make such reuse difficult at this point. Sure, in the future this can
get easier should the TLS vendors like the new extensions enough to
implement them, but until that, there is a risk of causing extra issues
to vendors who work with EAP implementation and just rely on external
TLS libraries..