Subject: RE: [eap] Basic facts about EAP

From: <[email-masked]>
Date: Thu, 28 Apr 2005 17:49:11 +0300

Bernard Aboba wrote:
>
> I have received a request that the following basic facts about
> EAP be posted to the EAP WG mailing list.
>
> a. EAP is a two party protocol, run between an EAP peer and
> server.  Saying EAP is an N-party protocol is like saying that
> TCP is a N-party protocol because TCP packets pass through
> routers.  Forwarding an EAP packet without modification does
> not cause an entity to become a "participant" in an EAP
> conversation any more than forwarding an IP packet turns a
> router into a host.

I fully agree. EAP is a two-party protocol between two entities.

However, EAP is always used as a component or "sub-protocol" in
a system which includes several other (sub-)protocols and
usually more than two entities.

I think one reason for the recent confusing discussions is that 
we do not have good _names_ for these systems and "mega-protocols".  
We do have the systems, though: whenever we're talking about 
N-party protocols or mentioning both EAP and RADIUS/Diameter/AAA 
in the same sentence, we're talking about some particular system
(that uses EAP protocol somewhere in it, but includes much more).

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Apr 2005 10:29:48 -0700 (PDT)

> should be a single correct system, and no other systems are allowed

Do you have a suggestion for how we might clarify the usage?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Thu, 28 Apr 2005 11:21:25 -0700

>> I have received a request that the following basic facts about
EAP be
>> posted to the EAP WG mailing list.
>> 
server.
>> Saying EAP is an N-party protocol is like saying that TCP is a
>> N-party protocol because TCP packets pass through routers. 
>> Forwarding an EAP packet without modification does not cause an
>> entity to become a "participant" in an EAP conversation any more
>> than forwarding an IP packet turns a router into a host.
> 
> However, EAP is always used as a component or "sub-protocol" in a
> system which includes several other (sub-)protocols and usually
more
> than two entities.  

I'm not sure how that is material: EAP is (or should be, IMHO) as
aware of things like RADIUS proxies or Diameter agents as HTTP is of
IP routers.

> 
> I think one reason for the recent confusing discussions is that we
do
> not have good _names_ for these systems and "mega-protocols". 
N-party
> protocols or mentioning both EAP and RADIUS/Diameter/AAA in the
same
> sentence, we're talking about some particular system (that uses
EAP
> protocol somewhere in it, but includes much more).   

This whole discussion is one of layering, a concept which I would
hope anyone on this or any other IETF list would be at least
familiar; unfortunately, that familiarity is not apparent in these
discussions.

> are considered to be parts of a single logical entity. 

No, it's not; well actually, it's fine if you are seriously confused
about the meanings of "logical" and "physical".  The fact that a
particular implementation (or for that matter, all implementations)
of EAP server(s) happen to run on the same box(es) or are even
integrated into the same code base doesn't mean that they are the
same thing, logically or otherwise.

> 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). 
> 
> Best regards,
> Pasi

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Apr 2005 14:06:37 +0300

Hi Glen,

>>system which includes several other (sub-)protocols and usually more than two entities.  
>>    
>>
>
I tend to agree with Pasi here. Even if EAP is a two-party
protocol, the complete system consisting of AAA and some
features of EAP have more than two entities. For instance,
EAP channel bindings specified in RFC 3748 help the system
to protect against compromise of individual NASes through
the system being aware of 3 entities, the information about
the NAS being in part communicated over EAP.

But yeah, Pasi's comment is more about the unnamed system
than it is about EAP protocol. The example above shows that
the layering is not as pure as might appear.

>same thing, logically or otherwise.
Here I agree with Glen.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Apr 2005 14:13:10 +0300

>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)
- AAA, running between NASes and servers in a fashion where
  the existence of the proxies is visible and known to the protocol
- EAP, running between the client and the servers, unaware
  of NASes unless channel bindings are being provided

--Jari

---

From: Artur Hecker <[email-masked]>
Date: Fri, 29 Apr 2005 17:43:25 +0200

hi

just some (pretty evident) thoughts on it:

>  of NASes unless channel bindings are being provided

I'd agree on (optional) AAA. However for the rest it might be better to 
use a higher abstraction level. For instance, I wouldn't restrict this 
"unnamed system" to network access issues only. I also don't really see 
why PANA would be strictly L3 and not e.g. L4 or higher :-) (since it 
uses EAP over UDP on the service link).

Perhaps we could talk about a "service access control system" instead. 
The service might be a network link with certain parameters (e.g. 802.11 
link with encryption, QoS, whatever else), an L3 service (e.g. IP 
obtained e.g. over PANA), an application layer service (there were some 
proposals for EAP in SIP or EAP in HTTP, etc., I think others might 
follow since it is a good idea to use established authentication 
protocols like the standard EAP methods), or anything else.

In this view, EAP appears as a pure user-service authentication 
protocol. Indeed, EAP does not specify any machine-bound identity, so 
e.g. "network access" appears to be too special or too low. "User" is an 
abstract name pointing to the "accessing entity", "supplicant" or 
"access requestor"; it can be  virtually anything, depending on the used 
service (which appears perfect). Note that in that particular context, 
"user" is also might better than the mentioned "client", because 
"client" is often confused with an NAS. (Btw, "NAS" is a particularly 
bad name: it is typically used in the context of AAA protocols where, 
strictly spoken, this entity is everything but a server; NAS is only a 
Network Access Server from the point of view of the _user_, who however 
is out of scope of the AAA protocol that itself is a two-party protocol).

So, EAP is used between the service requesting and the service providing 
entities (user and service provider?). Of course, the service providing 
entity may relay the requests to somebody else since EAP does not use 
any form of addressing. However, it is a service provider internal 
treatment; logically the service requestor is unaware of this 
difference. In that sense, I'd agree with Glen that, unless some special 
EAP method is used, the separation of the NAS and the AAA backend is 
completely transparent for the user.

Historically, AAA is just a convenient way to centralize the 
administration of the dispersed NASes :-)

-- 
___________________________________________________________
Artur Hecker
http://www.enst.fr/~hecker
ENST Paris ________________________________________________
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: John Vollbrecht <[email-masked]>
Date: Fri, 29 Apr 2005 13:11:10 -0400

On Apr 29, 2005, at 11:43 AM, Artur Hecker wrote:

> I'd agree on (optional) AAA. However for the rest it might be better 
> to use a higher abstraction level. For instance, I wouldn't restrict 
> this "unnamed system" to network access issues only. I also don't 
> really see why PANA would be strictly L3 and not e.g. L4 or higher :-) 
> (since it uses EAP over UDP on the service link).
>
> The service might be a network link with certain parameters (e.g. 
> 802.11 link with encryption, QoS, whatever else), an L3 service (e.g. 
> IP obtained e.g. over PANA), an application layer service (there were 
> some proposals for EAP in SIP or EAP in HTTP, etc., I think others 
> might follow since it is a good idea to use established authentication 
> e.g. "network access" appears to be too special or too low. "User" is 
> an abstract name pointing to the "accessing entity", "supplicant" or 
> "access requestor"; it can be  virtually anything, depending on the 
> used service (which appears perfect). Note that in that particular 
> context, "user" is also might better than the mentioned "client", 
> because "client" is often confused with an NAS. (Btw, "NAS" is a 
> particularly bad name: it is typically used in the context of AAA 
> protocols where, strictly spoken, this entity is everything but a 
> server; NAS is only a Network Access Server from the point of view of 
> the _user_, who however is out of scope of the AAA protocol that 
> itself is a two-party protocol).
>
> So, EAP is used between the service requesting and the service 
> providing entities (user and service provider?). Of course, the 
> service providing entity may relay the requests to somebody else since 
> EAP does not use any form of addressing. However, it is a service 
> provider internal treatment; logically the service requestor is 
> unaware of this difference. In that sense, I'd agree with Glen that, 
> unless some special EAP method is used, the separation of the NAS and 
> the AAA backend is completely transparent for the user.
>
I think this is a very useful discussion.  I agree that EAP is 
independent of NAS, AAA, etc.

In my view, EAP RFC  describes how EAP methods are controlled between a 
supplicant and an authenticator.  The supplicant and authenticator can 
be built into any processes that want to run EAP methods between each 
other.

The result of running EAP is represented by a success or fail which is 
passed to the processes running EAP between themselves.  It may also 
pass other information like key or state.  This does not depend in any 
way on the underlying protocol carrying EAP.

EAP runs EAP methods.  EAP methods implement different algorithms, most 
of the current ones are authentication, some of which provide tunnels 
in which other EAP Methods may be run.  Methods are run by EAP.  Each 
method is a set of messages.  The termination of an EAP method is a  
success or fail (at least in the authenticator), state (perhaps reason 
code), and (again perhaps) key.  Other things could be defined and 
perhaps should be, else EAP variables in methods will become part of 
the process calling them.

When EAP runs between processes it may be desirable to pass some info 
from the processes to EAP so that it can use that information when 
building keys so the keys are bound to the calling process.  One 
question in my mind is  whether the binding is done by having the EAP 
method pass a "unbound" key to EAP and having EAP do the binding, or to 
pass the information to the EAP method and have the method do the 
binding.

I am not sure if there are cryptographic reasons for doing binding one 
place  or the other.  I would be interested in understanding if those 
reasons exist and if so what they are.  From a structural design point 
of  view it seems that having EAP methods always produce the key and 
having the EAP process (or the process that calls EAP)  bind it might 
be simpler for EAP method implementers.  Then EAP methods could produce 
a key and callers could bind it to the process calling it in any way 
that seems appropriate for the particular application.

I am very interested in reactions to this way of thinking about EAP and 
interaction with other processes.  I don't think limiting EAP to use in 
AAA style systems is necessary or a good thing.  EAP use in IKEv2, 
PANA, and within PEAP, FAST, TTLS is making this important.   This 
seems a good topic to spend some time on at the next IETF.  It also 
seems to play into the Key Management issues.

John