Radius is now running with EAP/TLS (thanks for the great help for it). But now a few last questions. We are using Enterasys Access Points and they also offer the possibility to assign clients to vlans dynamically. I have searched a lot but found no information about it (for example which attribute to use). Has someone experience with this kind of problem?
that's interesting: do they really offer this possibility? or do they merely map SSIDs to VLAN-IDs?
if they do, the radius server probably has to send a Enterasys VSA back to the AP, this has nothing to do with freeradius list, you should ask at Enterasys.
Is it possible to disengage a certificate from users so that the radius server will not accept it any more. One possible solution of disabling an account is to set Auth-Type to Reject but an other user can still use the certificate so I don`t like it really.
this is out of scope, too. you've aswered your own question: in radius, it's much easier to disable the user account (e.g. by authorization), whatever authentication method is used.
if you want to "devaluate" the certificate, you will need a PKI with CRL support. this is basically completely out of scope, BUT remember that using CRL you will probably do the following:
(-install and manage a CRL)
- put an invalid user's certificate in the CRL
that means that each process using certificates will have to be updated in order to check the CRL in the first place. that's more complicated than it sounds, since the most software doesn't care about CRLs (freeradius doesn't e.g.) at the moment. also, the CRL management is complicated (in general). for each process, you will have to change the configuration, too (which CRL repository, what to do, how often).
- when you finally applied all this, you will have to decide the following: do you want to check the CRL regularly (how often?) or do you want to do an online check of the CRL? the advantage of the first is that the CRL (~PKI) doesn't have to be online at the moment of the verification (which so often has been advertised as a main advantage of PKIs). however, you have a problem: in which intervals should the CRL be contacted by the process? the processes will have to store the obtained CRL locally etc and so changes propagate slowly through network (e.g. you cancel a certificate, but the user can still log on till to the next CRL download).
this is far from optimal, so you will probably decide to ask your CRL at the login time - this is the state of the art in the PKI research. however, with CRL being online (and thus always available, the "main" PKI advantage gone...) you will have to use some protocol to ask the CRL about the validity. first: those protocols are still all in development, there is no accepted standard. second: since a CRL is a central repository, the procedure will increase your login delay (which can be an issue). third: what happens, if the CRL is not available (things happen...)? this is a problem, since normally CRL will only contain few certificates compared to the user-number, so blocking all users if the CRL is not available seems exaggerated, no? however, if you don't, invalid users can login...
and finally, having all this set up, you'll see that basically it is exactly the same principle as with radius, only one level higher. now, radius (and every other service) will have to ask some central authority if somebody can login. why bother? my opinion: set Auth-Type:=Reject in radius.
logically, i would defend this position as following: when your security agent at the entrance blocks a user because he doesn't know him, he doesn't try to cancel his ID card. in contrary, he accepts his ID and THUS prohibits entrance. why shouldn't the radius server simply do the same? let the certificate be the (abstract) identity and then we'll see if we let him enter. if he can't, we don't need to follow him and take away his identity. in this model, you probably don't want to certify real names of users. rather certify their abstract logins or their email adresses etc. for the duration of their studies at your school or for a year (semester, etc.) of studies.
Our Access Point also support EAP-TTLS. Will freeradius support this in future?
no, your access point doesn't support EAP-TTLS and never will. your access point supports 802.1X and thus EAPOL and EAP in RADIUS. the truth is that the Access Point doesn't know *anything* about TLS, TTLS or whatever other EAP method you use. an AP can't support something like that because there is nothing to support in the first place.
i think, there is some development work on EAP/TTLS in freeradius, likewise for PEAP.
And a last question! We are a school with about 2000 pupils. Has someone experience with the distribution of certificates and what you should care about it? The problem is we are using openssl to build our certificates. So we have to program something to make it easy for our students to request acertificate. Are there any existing products?
try OpenCA or something similar. it depends much on what you want to certify. i'm not a fan of PKIs (as you could recognize), so i would probably install some certificates only for binding the user-login to the corresponding private key, in order to be able to run TLS and similar. i would produce them by an openssl script out of some webpage available over SSL from within the school's (wired) LAN where every pupil can login with his login/password or whatever he's got. all authorization (can she login?, where?, why and with which restrictions?) should be left to RADIUS because you already have it and because it is something what radius is supposed to do. certificates become large and complicated to handle, when you put authorization information in them (like these dumb Extensions etc.)
ciao artur
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
