eap Mailing List: Re: Basic facts about EAP

[John Vollbrecht (jrv]

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

> hi
>
>
> just some (pretty evident) thoughts on it:
>
> Jari Arkko wrote:
> > 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
>
> 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 :-)
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