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.