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

[M. Vanderveen (mvandervn]

Lakshminath,

While the need for multiple EAP sessions is clear, the use case for parallel EAP sessions is not. As I understand it, the scenario where you have MVNOs, and where the terminal/user has two separate SAs with the local MVNO and the home network, and where the access network lets the terminal talk to the home network BEFORE the access network has authenticated the terminal, and saving time on this (initial) authentication is desirable --- can benefit from the EAP-GEE encapsulation. I agree with this. Any other use cases you have in mind - please share if possible.

 

As an aside, in the MVNO scenario it is a little strange that the EAP sessions are not sequential. Seemed to make more sense to let the access network complete authentication of the terminal before allowing conversations with the home network.

 

Also, one question that perhaps you could shed some light on - why should the mobile try to save time (not clear how much time) in this network access phase? - it would be understandable in the handoff scenario, but not necessarily on power-up. So, is this EAP encapsulation beneficial in MVNO handoff scenarios? I was thinking that access with the home network is only done every so often, whereby access to a different AP in the MVNO network should be done upon every handoff.

 

 

More inline.

Michaela

Lakshminath Dondeti <ldondeti [at] qualcomm.com> wrote:

Michaela,

It looks like you are confusing several things here. Please see
inline some clarifications.

At 11:51 AM 6/20/2006, M. Vanderveen wrote:
>While a solution for demultiplexing several EAP sessions might be
>helpful, part of the resistance to the introduction of this sublayer
>is probably due to the fact that there are ways around this issue.

There is a need for parallel EAP authentications; that has been
clearly expressed by some operators. EAP (RFC 3748 and its ilk) does
not have support for multiple parallel authentications. We can
either do what Alper says and provide support in every lower layer,
or do it in a lower layer agnostic fashion. This is a new feature
(not supported in any lower layer) and so doing it at the EAP level
would be a universal solution and makes perfect sense.

 

MCV>>I don't disagree that there is a need for multiple EAP sessions - the above message just says that there are other ways of achieving this.

>
>It's not clear to me why we are trying to inform the peer as whether
>the current EAP session is for service vs. for access. Looking at
>the newly emerged EAP-GPSK, all the peer needs to know is the ID it
>gave the server and the server ID, in order to pull out the correct
>security association to carry out EAP-GPSK. It can be informed
>whether access or service was granted *after* this is all done, by
>some other means that have nothing to do with EAP.

GEE has little to do with methods, period. I am not sure which part
of the I-D gave you that impression. Could you please point any
sections that led you to this confusion? We would like to fix it.

MCV>> There is no confusion. The draft is clear in its proposal of an encapsulation for EAP packets. I'm just saying that the peer can tell by the ID it used (a MAC address vs. a NAI, for example), what kind of authentication this is. However if you want to be able to interleave packets from multiple EAP methods, and you are not willing to rely on any Session ID or some other EAP-method-specific identifier, then an elegant solution would be to encapsulate it, as in EAP-GEE

>
>In the network that we have deployed, and in others that we hope to
>deploy some day, multiple EAP sessions do come into play but the
>overall authentication mechanism can be made to work in a fairly
>simple fashion without any additional EAP-related mechanisms/layers.

As I note above, the multiple parallel authentications use case came
from operators. Next, I am concerned about your phrase "can be made
to work"; if you mean proprietary hacks by that, that's not really
desirable, is it?

 

MCV>> There is no hack in allowing sequential EAP methods.

best regards,
Lakshminath

>
>Michaela
>
>Nakhjiri Madjid-MNAKHJI1 wrote:
>
>-----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
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com

---

Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.