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

From: "Cao Zhen" <[email-masked]>
Date: Thu, 1 Jun 2006 18:42:51 +0800

Hello, Lakshminath and Peter

Thanks for your reply,
>> These questions seem very 3GPP2 specific, so I will ask folks
>> knowledgeable in 3GPP2 to respond to you offline.
please allow me to ask by following IETF style.

What kind of service here means, network access (MVNO) or any others
(SIP)?

If in the case of MVNO, here NAS2 means only for network access?

Many Thanks,

Zhen

-----Original Message-----
From: Lakshminath Dondeti [email-masked]
Sent: 2006-05-31
To: Cao Zhen; [email-masked]
Subject: Re: [eap] Questions for draft-barany-eap-gee-01

These questions seem very 3GPP2 specific, so I will ask folks 
knowledgeable in 3GPP2 to respond to you offline.

regards,
Lakshminath

At 07:15 PM 5/25/2006, Cao Zhen wrote:
>Hi Peter,
>
>I have two questions about this draft.
>1) What kind of device you are assuming for NAS2 in 3GPP2:
>      such as Home Agent or P-CSCF.
>
>2) Could this solution be applied to 3GPP2 MMD solution?
>suppose NAS2 is a kind of P-CSCF, then could this solution
>establish IPsec SA between mobile station and P-CSCF?
>
>Best Regards
>------------
>Cao Zhen, Ph.D Candidate
>Information Security Laboratory
>School of Electronics Engineering and Computer Science
>Peking University
>Beijing 100871, P.R.China
>
>
>
>
>_________________________________________________________________
>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

---

From: "Quinn Li" <[email-masked]>
Date: Tue, 13 Jun 2006 12:33:58 +0800

Hi Cao, Lakshminath and Peter,

I read the draft and was going to ask the same question about what
kind of service GEE supports :). Currently draft have well described
its usage in MVNO scenario. But it is still unclear to me how GEE can
support other services like IMS, Mobile IPv6, or any other service,
you name it.

Before further description supplied, I'm holding the opinion that this
solution has a quite limited usage in industry and oppose to accept it
as a general purpose protocol. Since that problem could be solved by
other way.

Best regards,
Qin

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Jun 2006 21:57:50 -0700

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.

With your last statement, are you saying that there is another way to 
demultiplex multiple parallel EAP exchanges?  If so, I would like to 
read about it.   Please share the reference.  Thanks.

regards,
Lakshminath

---

From: "Quinn Li" <[email-masked]>
Date: Tue, 13 Jun 2006 13:37:12 +0800

Hi Lakshminath,

Thank you for your immediate response.
My comments are included inline.

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

> support for those services.
Not exactly, EAP is supported in Mobile IPv6 authentication. Please
refer to section 8 "The use of EAP authentication" in
draft-ietf-mip6-ikev2-ipsec. Does that mean GEE draft can support
services like Mobile IPv6 as long as it uses EAP authentication? But
How?

> read about it.   Please share the reference.  Thanks.
By another way, I mean in most circumstances except MVNO, multiple
parallel EAP exchange can be demultiplexed by the underlying protocol
of EAP. For example, if you want to have two Mobile IPv6
authentication done simultaneously, you can initiate two IKE with two
different Home Agent.

> snip

Thanks
Qin

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 13 Jun 2006 00:01:53 -0700

Thanks for the explanation.  IKEv2 and the use of EAP with that 
protocol brings up some interesting issues to fore, and GEE is no 
exception.  One of the other issues for example is the use of the MSK 
is different.

At 10:37 PM 6/12/2006, Quinn Li wrote:
>Not exactly, EAP is supported in Mobile IPv6 authentication.

Right, sorry for the oversight.  I sort of missed the IKEv2-EAP use 
case there, although I wonder whether the point about the same 
authenticator having to demultiplex multiple EAP conversations 
applies.  The other thing to think about is whether the EP would be 
the same for the multiple authentications.

>Please

You seem to be answering this question yourself, below.  Please see 
there for some more thoughts from my end.

>of EAP.

I am not sure whether that is the case in most circumstances, but 
IKEv2 might be an exception, although I will point out that there 
doesn't seem to be a need for multiple simultaneous EAP 
authentications in case of IKEv2.  Perhaps you have a use case in mind?

>For example, if you want to have two Mobile IPv6

This goes to my point earlier about the authenticators being 
different and/or EPs being different too.

If the same authenticator using IKEv2 has a use case to run multiple 
simultaneous EAP authentications, the IKEv2-EAP specification would 
need to be changed to signal it, but GEE could very much be part of 
the solution to demultiplex the multiple EAP runs.

If there are multiple IKEv2 sessions, you are right, the IKEv2 SA can 
be used to demultiplex, but binding the two EAP authentications might 
be difficult, so the multiple IKEv2 sessions might not be a viable 
solution for multiple parallel EAP authentications and enforcement thereof.

regards,
Lakshminath

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 Jun 2006 13:13:56 -0700

> read about it.   Please share the reference.  Thanks.

I don't see any inherent problems with an EAP lower layer performing such
multiplexing, if they are really after such an optimization. Especially not
to the extent that one needs to design a new layer to solve the problem.
 
Alper

---

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

At 01:13 PM 6/13/2006, Alper Yegin wrote:
>multiplexing, if they are really after such an optimization.

The advantage of doing this at the IETF is to design it at the EAP 
level and allow use by multiple lower layers and multiple 
purposes.  The original authors had one use case, Joe and Parviz 
joined us with another use case.  Designing support for multiple EAP 
conversations is not new at the IETF.  All that GEE is doing is 
adding support for parallel authentications.

>Especially not

No, GEE is *not* another "layer."  If EAP had an extra field in the 
header, GEE might not have been needed.

best,
Lakshminath

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 15 Jun 2006 11:08:45 -0700

You were earlier questioning if parallel EAP runs was ever possible. This is
different than saying you'd design it once for all L2s. 

Regarding the first question, in fact, I don't know if there is any EAP
lower layer that cannot achieve what you are looking for. 

It's true EAP does not have extra fields for this use (by design!), but the
"EAP lower layers" do have. And that's where the functionality you are
seeking belongs to.

I also find your "layering" responses very confusing. If EAP-GEE is not a
layer, why does your document call it "GEE layer" and nicely puts it below
the "EAP layer"?

                Peer                   Authenticator
        +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
        |           |           |  |           |           |
        | EAP method| EAP method|  | EAP method| EAP method|
        | Type = X  | Type = Y  |  | Type = X  | Type = Y  |
        |       V   |           |  |       ^   |           |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        |  EAP  ! Peer layer    |  |  EAP  ! Auth. layer   |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        |  EAP  ! layer         |  |  EAP  ! layer         |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        |   GEE ! layer         |  |   GEE ! layer         |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        | Lower ! layer         |  | Lower ! layer         |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                !                          !
                !                          !
                +------------>-------------+

Alper

> From: Lakshminath Dondeti [mailto:[email-masked]]
> Sent: Tuesday, June 13, 2006 1:43 PM
> To: Alper Yegin; 'Quinn Li'; 'Cao Zhen'
> Cc: [email-masked]
> Subject: RE: [eap] Questions for draft-barany-eap-gee-01
>

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 20 Jun 2006 11:01:30 -0400

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Monday, June 12, 2006 11:58 PM
To: Quinn Li; Cao Zhen
Cc: [email-masked]
Subject: Re: [eap] Questions for draft-barany-eap-gee-01

Hi,

scenarios well, so I guess we can safely conclude that it does its job
then.

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.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 20 Jun 2006 11:06:35 -0400

Madjid>>I am trying to understand all this. EAP WG is closing, which
means that it does not accept any new WG items? So first of all this WG
is not the place to standardize anything new. Second even if it were. To
standardize a new item, first people describe the problem, then get it
approved as a problem that needs to be solved by the WG (i.e. WG item),
then people debate about how to solve it and if there are multiple
solutions which one is best.
Not only I think this has not yet been established as a legitimate
problem, but also I think challenging people by demanding an alternate
solution is not quite the IETF way to do things.

Madjid

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Jun 2006 11:10:49 -0700

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

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 8:02 AM
> To: Dondeti, Lakshminath; Quinn Li; Cao Zhen
> Cc: [email-masked]
> 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.
> 
> If the idea is to standardize the usage, then it should not 
> be customized for a specific use case.
>

---

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

Perhaps you missed the earlier emails on this and the presentation in
Dallas? This is not requested as a work item for the EAP WG - we are
only soliciting comments and feedback from the WG participants - the
draft itself will be an individual submission to the IESG. 

Vidya

> Sent: Tuesday, June 20, 2006 8:07 AM
> Subject: [eap] New work item in EAP WG??: Questions 
> fordraft-barany-eap-gee-01
> 
> 
> means that it does not accept any new WG items? So first of 
> all this WG is not the place to standardize anything new. 
> Second even if it were. To standardize a new item, first 
> people describe the problem, then get it approved as a 
> problem that needs to be solved by the WG (i.e. WG item), 
> then people debate about how to solve it and if there are 
> multiple solutions which one is best.
> Not only I think this has not yet been established as a 
> legitimate problem, but also I think challenging people by 
> demanding an alternate solution is not quite the IETF way to 
> do things.
> 
> Madjid
> 
> With your last statement, are you saying that there is 
> another way to demultiplex multiple parallel EAP exchanges?  
> If so, I would like to

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 20 Jun 2006 14:34:18 -0400

I did not miss the presentation. I may have missed a few emails here and
there, given their number, but I missed on the IESG submission, in that
case this work needs to be better communicated to the rest of security
and AAA community.

Madjid

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 1:13 PM
To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen
Cc: [email-masked]
Subject: RE: [eap] New work item in EAP WG??: Questions

Vidya

---

From: "M. Vanderveen" <[email-masked]>
Date: Tue, 20 Jun 2006 11:51:15 -0700 (PDT)

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

Nakhjiri Madjid-MNAKHJI1 <[email-masked]> wrote:

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Monday, June 12, 2006 11:58 PM
To: Quinn Li; Cao Zhen
Cc: [email-masked]
Subject: Re: [eap] Questions for draft-barany-eap-gee-01

Hi,

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 20 Jun 2006 14:58:09 -0400

I agree, it seems that AAA functions that are typically done after
authentication are introduced into EAP messaging, while EAP is just a
protocol to carry authentication exchanges. EAP is an "authentication"
protocol, not a AAA protocol.

Madjid

________________________________

From: M. Vanderveen [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 1:51 PM
To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao Zhen
Cc: [email-masked]
Subject: Re: [eap] Questions for draft-barany-eap-gee-01

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. 

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. 

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. 

Michaela

	
	-----Original Message-----
	From: Lakshminath Dondeti [mailto:[email-masked]] 
	Sent: Monday, June 12, 2006 11:58 PM
	To: Quinn Li; Cao Zhen
	Cc: [email-masked]
	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.
	
So, in 

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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 20 Jun 2006 15:07:29 -0400

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. 

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. 

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:[email-masked]] 
Sent: Tuesday, June 20, 2006 1:11 PM
To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen
Cc: [email-masked]
Subject: Re: [eap] Questions for draft-barany-eap-gee-01

Madjid,

Thanks,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Jun 2006 12:19:13 -0700

Michaela, Madjid,
GEE has nothing to do with AAA or EAP methods - it is about
demultiplexing multiple parallel EAP sessions at the peer and the
authenticator. So, I find this exchange a bit confusing. 
 
Vidya

	From: Nakhjiri Madjid-MNAKHJI1
[mailto:[email-masked]] 
	Sent: Tuesday, June 20, 2006 11:58 AM
	To: M. Vanderveen; Dondeti, Lakshminath; Quinn Li; Cao Zhen
	Cc: [email-masked]
	Subject: Re: [eap] Questions for draft-barany-eap-gee-01

	I agree, it seems that AAA functions that are typically done
after authentication are introduced into EAP messaging, while EAP is
just a protocol to carry authentication exchanges. EAP is an
"authentication" protocol, not a AAA protocol.

	Madjid

	From: M. Vanderveen [mailto:[email-masked]] 
	Sent: Tuesday, June 20, 2006 1:51 PM
	To: Nakhjiri Madjid-MNAKHJI1; Lakshminath Dondeti; Quinn Li; Cao
Zhen
	Cc: [email-masked]
	Subject: Re: [eap] Questions for draft-barany-eap-gee-01

	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. 

	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. 

	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. 

	Michaela

		
		-----Original Message-----

		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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Jun 2006 12:21:19 -0700

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
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 20 Jun 2006 20:37:57 -0700

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:
>helpful, part of the resistance to the introduction of this sublayer 

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.

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

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

best regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 20 Jun 2006 20:40:38 -0700

At 11:58 AM 6/20/2006, Nakhjiri Madjid-MNAKHJI1 wrote:
>authentication are introduced into EAP messaging, while EAP is just 
>a protocol to carry authentication exchanges. EAP is an 

I am confused here.  I see no reference to AAA, especially the AAA 
protocol, in the emails below.  What are you referring to?

Lakshminath

>----------

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 21 Jun 2006 12:00:52 -0400

Inclusion of information regarding access versus service is an
authorization act.

Madjid

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 10:41 PM
To: Nakhjiri Madjid-MNAKHJI1; M. Vanderveen; Quinn Li; Cao Zhen
Cc: [email-masked]
Subject: RE: [eap] Questions for draft-barany-eap-gee-01

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 21 Jun 2006 09:35:54 -0700

I still don't understand how what you write below is relevant to the 
discussion at hand, but anyway, I think I made my point.

I will note that the word "service" seems to throw people off into 
debates on authentication vs. authorization and that may be what's 
happening here.  If it helps, perhaps the use of the terms L2 access 
and L3 access might be better.

Further, multiple parallel authentications could also be for device 
and user authentications as Kuntal points out.  Other use cases are 
also possible.

regards,
Lakshminath

---

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 21 Jun 2006 11:47:11 -0700 (PDT)

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 <[email-masked]> wrote:
    Michaela,

   
  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.

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

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

best regards,
Lakshminath

>
>Michaela
>
>Nakhjiri Madjid-MNAKHJI1 wrote:
>

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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 21 Jun 2006 19:44:13 -0400

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 11:36 AM
To: Nakhjiri Madjid-MNAKHJI1; M. Vanderveen; Quinn Li; Cao Zhen
Cc: [email-masked]
Subject: RE: [eap] Questions for draft-barany-eap-gee-01

Madjid>>Not sure what that means, but I guess that is good for you.

happening here.  

Madjid>>yes,

If it helps, perhaps the use of the terms L2 access 
and L3 access might be better.

Madjid>>Ok, that is better, but still L3 access is vague: is it getting
IP addresses? Setting IP connectivity? And regardless of what it means,
multiplexing multiple purposes in one EAP signaling, means you need to
include indication for these purposes in the EAP signaling. I don't know
how you would do it in a way that does not break existing
implementations of EAP? 

Madjid>> There are many cases, if not all cases, where device and user
authentication do not happen in parallel but in series as a form of
multifactor authentication.

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 21 Jun 2006 18:44:14 -0700

Michaela,
Multiple authentications may occur in the MVNO cases even when switching
L3 subnets (both L2 and L3 access authentications would need to be
performed there) - so, it is not strictly a power on only scenario. This
does have an impact on handoffs as well. 
 
Vidya

	From: M. Vanderveen [mailto:[email-masked]] 
	Sent: Wednesday, June 21, 2006 11:47 AM
	To: Dondeti, Lakshminath
	Cc: [email-masked]
	Subject: Re: [eap] Questions for draft-barany-eap-gee-01

	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

		Michaela,
		
		It looks like you are confusing several things here.
Please see 
		inline some clarifications.
		
		>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.
		
		>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
		
		>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
		
demultiplexing of
and an
MVNO
it does its job
is it? So, in
specify
IMS.
not be

	

	Yahoo! Messenger with Voice.
<http://us.rd.yahoo.com/mail_us/taglines/postman3/*http://us.rd.yahoo.co
m/evt=39666/*http://messenger.yahoo.com>  PC-to-Phone calls for
ridiculously low rates.