eap Mailing List: Re: Questions for draft-barany-eap-gee-01

[Narayanan, Vidya (vidyan]

Madjid,

> 
> First of all, multiple parallel EAPs between who and whom. In 
> general case one end is the peer but the other end is not 
> always the same. 
> 

This is clearly explained in the draft - do you find that explantion to
not be adequate? If so, it would help if you point out the issues with
the details in the draft. 

> Second, I can see a case where you have to do both IMS 
> authentication and MIP6 authentication, not sure if 
> "parallelism" can be achieved but that is just the nature of 
> the beast. 
> 

It is about running them in parallel on the same lower layer. IMS and
MIP6 are different services - I don't see any reason why you can't
authenticate for both in parallel with what is available today. 

Vidya

> Third, when I want to design a system, I usually look for the 
> best solution for each system, not why a specific solution 
> cannot be used. I just don't see anything remarkable about 
> putting a new layer in EAP except the adding complexity to 
> something that is already too complex. I personally cannot 
> justify spending the time explaining all the EAP keying 
> layering concepts to an implementer under deadline pressure, 
> let alone adding yet another layer through an addendum to EAP 
> keying. I have already seen that nobody but a small group of 
> people understands the layering concepts anyway.
> 
> Madjid
> 
> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan [at] qualcomm.com]
> Sent: Tuesday, June 20, 2006 1:11 PM
> To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen
> Cc: eap [at] frascone.com
> Subject: Re: [eap] Questions for draft-barany-eap-gee-01
> 
> 
> Madjid,
> There is no customization for any specific use case. GEE can 
> be used any
> time multiple parallel EAP runs are needed on a given lower layer. I
> don't, however, see a use case where multiple parallel runs 
> of EAP will
> be required for a service such as MIP6 or IMS. If there is such a use
> case, there is no reason why GEE cannot be used. 
> 
> If you think of a case where GEE cannot be used to 
> demultiplex multiple
> parallel EAP exchanges, please share your thoughts on it. 
> 
> Thanks,
> Vidya
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 
> [mailto:Madjid.Nakhjiri [at] motorola.com] 
> > Sent: Tuesday, June 20, 2006 8:02 AM
> > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen
> > Cc: eap [at] frascone.com
> > Subject: Re: [eap] Questions for draft-barany-eap-gee-01
> > 
> > 
> > 
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti [at] qualcomm.com]
> > Sent: Monday, June 12, 2006 11:58 PM
> > To: Quinn Li; Cao Zhen
> > Cc: eap [at] frascone.com
> > Subject: Re: [eap] Questions for draft-barany-eap-gee-01
> > 
> > Hi,
> > 
> > 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.
> > 
> > EAP is not used for IMS or Mobile IPv6 authentication, is it? 
> >  So, in simple terms, it's not the purpose of the GEE draft 
> > to specify support for those services.
> > 
> > Madjid>>EAP is being used for non-cellular access into IMS.
> > EAP is being considered for MIP6 bootstrapping.
> > If the idea is to standardize the usage, then it should not 
> > be customized for a specific use case.
> > 
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> > 
> > Arhives: http://lists.frascone.com/pipermail/eap
> > 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>