Subject: RE: [eap] Basic facts about EAP

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 2 May 2005 03:12:54 -0500

Hi Jari,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Friday, April 29, 2005 6:13 AM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: [eap] Basic facts about EAP

Bernard Aboba wrote:

>>And there's no single correct system, either. For instance, it's
>>perfectly OK to have a system where both EAP server and RADIUS server
>>are considered to be parts of a single logical entity. But nothing
>>in the components (EAP or RADIUS) implies or forces this: it is
>>this unnamed system that is making this definition. But since we
>>don't have good names for these systems, it's easy to get a
>>disagreement when two people are, in fact, talking of two different
>>systems that happen to use EAP (or are arguing that there is or
>>should be a single correct system, and no other systems are allowed
>>to use EAP).
>>    
>>
>
>Do you have a suggestion for how we might clarify the usage?
>  
>
I usually refer to the system as the "network access control
system", though this works only when EAP is used where
it was originally intended to be used. The system consists
of clients, NASes, proxies, and servers, and has three main
protocols:

- First hop, either on L2 (e.g. 802.11i) or L3 (e.g. PANA, IKEv2)

Madjid>> Ok, I guess so we are rulling out the EAP proxy model that has been proposed?

Peer------L2-------AP-----???-----NAS

Note that L3 may not be possible, given that in many network IP layer configuration follows the initial authentication and key distribution, so that rules out PANA or IKEv2, no?

- AAA, running between NASes and servers in a fashion where
  the existence of the proxies is visible and known to the protocol

Madjid>> This rules out sending the keys to a non-NAS node??

- EAP, running between the client and the servers, unaware
  of NASes unless channel bindings are being provided

Madjid>>See, this is where I have problem with the existing way of thinking: people have been saying that it is wrong to call EAP anything but a 2 party model, EAP is unaware of NAS, fine. But EAP requires functionalities from AAA entities such as NAS and has requirements on where the keys should be sent, how they are cached or named.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 May 2005 11:27:26 +0300

>
>
>Ok, I guess so we are rulling out the EAP proxy model that has been proposed?
>  
>

My description was made mainly from the point of view of
existing EAP usage. I didn't want to rule out future needs,
they were simply not considered in the description. Any
extensions would of course have to be considered carefully,
and at this point in time backwards compatibility dictates
a lot of course. But I don't want to "rule out" anything.

--Jari