EAP processing again

[Alan DeKok]

Emmanuel BILLOT wrote:
> Ok i read all of the debug output, and i think i can understand
> mechanism. However could you confirm (or not) what i understand ?

  I'm trying to figure out why you need to understand it.  The details
of the EAP flow are complex.  You don't need to understand them.  You
just configure the server.

> In case of an EAP/TTLS connexion :
> 
> - Freeradius get a request, with a particular attribut : EAP-Message
> - Entering authorize section, only EAP one matches because of EAP
> attribut => Auth-Type is set to EAP
> - Entering authenticate section, Freeradius sent a challenge to client

  If you're going to be technical, the *EAP* module creates an
EAP-Message, a State, and then tells the server to send a challenge to
the client.

  You can't go halfway on the details.  Either ignore the details
entirely, or understand them fully.  Any intermediate step is a disaster.

> - Client answer
> 
> - Freeradius get a new request with attribut EAP-Message, State and a
> new Message-Authenticator

  *All* Message-Authenticators are unique to the packet.  It's used to
sign packets.  It is *not* used for anything in EAP.

  The State attribute is used to match a challenge.  The EAP module uses
it to match the packet to an ongoing EAP conversation.

> - Entering authorize section, EAP matches
> - Entering authenticate section. EAP matches (Auth-Type = EAP).
> Freeradius sent response to client (negociating ?)

  Again, the EAP module runs.  It finds an EAP sub-module to run, and
hands over control to it.

> - Client answer
> 
> - Freeradius get a new request with attribut EAP-Message, State and new
> Message-Authenticator
> - Entering authorize section, EAP matches, tunnel setup is set
> - Entering authenticate section. EAP matches (Auth-Type = EAP). TTLS
> type found, beginning with TLS. SSL working, sending response to client
> 
> - Client answer
> 
> - Freeradius get a new request with attribut EAP-Message, State and new
> Message-Authenticator
> - Entering authorize section, EAP matches, tunnel continues
> - Entering authenticate section. EAP matches (Auth-Type = EAP).
> Negociating SSL, sending response to client
> 
> - Client answer
> 
> - Freeradius get a new request with attribut EAP-Message, State and new
> Message-Authenticator
> - Entering authorize section, EAP matches, tunnel continues
> - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL
> tunnel negociated, sending response to client
> 
> - Client answer
> 
> - Freeradius get a new request with attribut EAP-Message, State and new
> Message-Authenticator
> - Entering authorize section, EAP matches, tunnel continues
> - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL
> tunnel negociated, session establisshed, sending response to client

  That's all largely correct.  But again, I have to question *why* you care.

> - Client answer
> 
> - Freeradius get a new request with attribut EAP-Message, State and new
> Message-Authenticator
> - Entering authorize section, EAP matches, tunnel continues
> - Entering authenticate section. EAP matches (Auth-Type = EAP). Session
> establisshed, entering inner-tunnel section.
> A this time, no more EAP request/send, only new authorise/authenticate
> in the tunnel.

  No.  As I said before, the TLS tunnel contains authentication data.
That data is used to create a "fake" request.  That fake request is run
through the "inner-tunnel" virtual server.

  The purpose of the "inner-tunnel" virtual server is to virtualize the
configuration.  PEAP and TTLS can share the same "inner-tunnel".  You
can treat the "inner-tunnel" just as if it received a normal RADIUS packet.

  The other RADIUS servers do *not* have this feature.  The
"inner-tunnel" authentication is handled by various special-purpose
magic.  That makes the configuration more complex and hard to understand.

> - Entering inner-tunnel authorize section, LDAP matches

  No.  The *entire" authorize section is processed.  Whatever modules
are their do things to the request.

> - Entering LDAP section : bind successful, login is authenticated

  No.  After authorize, the "authenticate" section is called.  This used
whatever Auth-Type was set in the "authorize" section.

> - Access-Accept is send to client

  Absolutely not.  You've missed a LARGE part of the debug output.

  The inner-tunnel returns "Access-Accept".  The default (outer) virtual
server then continues it's work.  This often means a number of more EAP
exchanges with the client.

  Once the outer EAP session is done, the server returns an
Access-Accept to the client.

> If i'm right, i'm asking some questions :
> - in the first step of the connexion, what is exactly the job of
> authorize section ? Does it only set auth-type when finding any "clue"
> in the request ?

  That's the job of the authorize section.  It sets Auth-Type, and
*anything else* you need it to do.

> - when connexion is in the tunnel step, a "reduced" request is sent (
> without EAP attributes).

  No.  As I said, this is the data from inside of the TLS tunnel.  This
*may* contain EAP.

  It's just like HTTPS versus HTTP.  You connect to a web server via
HTTPS.  There's a lot of SSL magic involved.  Once the tunnel is set up,
you JUST USE HTTP over the tunnel.

> This request is checked by the inner-tunnel
> authorize section which will set the auth-type, right ? Here the
> auth-type found is LDAP.

  The authorize section does the same thing everywhere.  There's no
difference in handling between the inner-tunnel and outer "authorize"
sections.  The *contents* are different.  The *packets* they receive are
different.  But they do the same thing.

> If i follow the entire log, i can see
>     - entering authorize
>     - finding Ldap Auth
>     - entering LDAP section, and then bind...
> But i can't see entering authenticate section as we can see in the firt
> step with EAP

  Then you missed it.

> It's quite hard to explain, but
> * Outside tunnel : request -> authorize section -> Foudn type EAP ->
> authenticate section -> EAP working
> * Inside tunnel : request -> authorize section -> Foudn type LDAP ->
> LDAP working
> 
> Why is there an "authenticate section" for EAP 

  Because it's needed.

> and a direct use of LDAP section for LDAP ?

  There isn't.  Read the debug output.

  Alan DeKok.