Subject: Re: [eap] +AFs-eap+AF0- Questions for draft-barany-eap-gee-01

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 13 Jun 2006 11:18:36 -0700

> 
> 
> > >>GEE is not a general purpose authentication protocol.  It
> > is a generic
> > >>EAP encapsulation mechanism that allows demultiplexing of 
> multiple 
> > >>simultaneous EAP conversations between a peer and an
> > authenticator.  
> > >>You say that the draft does describe the MVNO scenarios 
> well, so I 
> > >>guess we can safely conclude that it does its job then.
> > >Yes, I know GEE allows demulitplexing multiple EAP
> > conversation. AFAIK,
> > >MVNO is currently the only application for GEE. Do you have
> > any other
> > >application in your mind?
> 
> Here no reply for author's company, 
> so I suppose there will be no any other applications existed.
> it means GEE could only be used for network access scenario,
> and doesnt support any service.
> It also means EAP demultiplexing is only needed for network acess.
> So the application will be quite narrow, 
> I could not understand why this solution could be accepted by WG.
> 

GEE is not an authentication protocol, as you have correctly understood.
Anything that requires parallel runs of two EAP sessions can use GEE -
the only lower layer that doesn't need this is IKEv2 (since it does much
beyond functioning just as an EAP lower layer). All other lower layers
need a mechanism like GEE to demultiplex the parallel EAP exchanges.
Examples of usage scenarios can be MVNO-based network access, device and
user authentication, etc. The MVNO case has been identified as the one
that immediately requires a solution - hence, GEEv0 has been tailored
for this. However, the protocol has been written in an extensible manner
(the current draft has details on how GEEv1 can extend the protocol for
generic multiple EAP authentications) - so, future versions of GEE can
support multiple EAP exchanges for other purposes as well. 

Hope that helps. 

Regards,
Vidya
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 13 Jun 2006 13:36:22 -0700

> > Here no reply for author's company,

Let's keep this at individual level, please.  I said that the GEE 
encapsulation is generic, also more on the applicability below.

> > I could not understand why this solution could be accepted by WG.

Adding to Vidya's notes, I would like to make a rather simple 
observation.  EAP is after all at its core for access 
authentication.  GEE supports demultiplexing of multiple parallel EAP 
conversations, for instance L2 access plus L3 access, and device plus 
user access authentications.  So, GEE has the same/similar scope as 
EAP.  Sure, we identified the IKEv2 case as special, but that is so 
in various ways, and not just on GEE, compared to many other lower layers.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jun 2006 10:38:54 -0400

Parallel EAP exchanges must be a functionality of EAP lower layer, not
a shim layer like GEE because RFC 3748 and RFC 4137 do not assume a
shim layer betwen EAP layer and lower layer.  Introducing a shim layer
heavily impacts on existing lower layer deployments and we must avoid
it.  I never figure out how GEE can work with IEEE 802.1X that does
not allow shim layer on top of it.

There are several lower layers that already define serial EAP
exchanges, PANA, IKEv2 (draft-eronen-ipsec-ikev2-multiple-auth-01.txt)
and IEEE 802.16e.  Those lower layers can also define parallel EAP
exchanges.

Yoshihiro Ohba

---

From: "Quinn Li" <[email-masked]>
Date: Wed, 14 Jun 2006 23:27:04 +0800

Hi Vidya,

> support multiple EAP exchanges for other purposes as well.

I still wonder why there is a need for parallel EAP goes to same
authenticator except MVNO?

Thanks.

Best regards,
Qin