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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html