I apologize for sending out another posting again. I forget to include the cfg file for radiator in case this may help for reproducing my problem.
Also, Mike, please ignore my question. It looks like the eap_tls.cfg takes care of identifying which server certificate to use already, which I grossly overlook and forget. On Tue, 11 Mar 2003, Bon sy wrote: > Denis and all others, > Thank you for the comment. Please read on .... > > On Tue, 11 Mar 2003, Denis Pavani wrote: > > > Did you install user certificates on XP? > > I did -- at least that's what I think. I made two different attempts. > > First attempt, I generate my own certificates below valid for one month > from March 9: > > For the server: bonnet17.der, bonnet17.p12, bonnet17.pem > For the client: bonsy.der, bonsy.p12, bonsy.pem, root_bonsy.der > > I install the client certificate (install certificate root_bonsy.der to > the root trusted certificate store and subsequently bonnet17.p12). > > I also put bonnet17.der, bonnet17.p12, bonnet17.pem in the subdir where > the path pointing to it is specified in eap_tls.cfg file where radiusd is > reading from for the initialization. > > QUESTION: This part I never understand. I think in FREERADIUS one has to > configure/make/make install for the radius to know which server > certificate to use. How exactly does it work in radiator for it to know > which certificate to use when there are multiple certificates sitting > there? Mike, any chance you can help me to understand this? > > Second attempt I use the certificates Hugh and Mike put in the patch of > radiator 3.5: > > For the server: cert-srv.pem > For the client: root.der, cert-clt.p12 > > Same problem as the first attempt, I did not get radiator receiving > request from XP via the Cisco AP 350. The setup for the Cisco AP 350 is in > the attachment cisco__eap_setup.doc which has a number of screen shots. > > Nevertheless, in one occasion, I saw (eap like) access request to radiator > but it stops at the access request state. It looks like the challenge > process did not go through properly. But when I reset and try to reproduce > the situation again, the radiator went silent again. On this particular > occasion, the certificates of BOTH attempts are in the client as well as > server. > > I wonder anyone out there could help to reproduce the setup of AP 350, and > try the certificates in the attachments and see whether my problem could > be reproduced. If one can get it to work using my certificates and setup, > at least I will be able to tell the problem is not on the certificates. > > The reason I suspect there could be a certificate problem is because I was > reading the "HowTo: EAP-TLS setup ..." by Ken Roser. He mentioned that the > server certificate must contain an EKU (Enhanced Key Usage) of > 1.3.6.1.5.5.7.3.2 for it to be useable for Windows 20000 server. I do not > think this is the case for the certificates that I generated, nor is it > the case for the testing certificates that Hugh distributes. But this > should not be the point if the EKU requirement is only for the Windows > server, which is not my case (I am using Linux server). > > I will deeply appreciate if anyone out there has a similar setup and is > willing to help to test out the certificates and the AP setup. > > Bon > > > > > > > Bon sy wrote: > > > > >Hi Christian, John, and Mike, > > > > > > I have a similar problem as John on getting the 802.1X client of > > >XP to work with the radius via Cisco 350 AP -- except I am looking into > > >EAP-TLS. > > > > > > I have the same setup on the 802.1x client side. I follow the > > >document reference mentioned in eap_tls.cfg for the setup, but no luck. I > > >talked to Mike and he emailed me the screen shot of the Cisco (340?) AP > > >set up required to work with the EAP-TLS. I follow that and use the > > >certificate Hugh mentioned not too long along for the test. Still no luck. > > > > > > When I initially config the AP and check both EAP and Mac > > >authentication in the "security tab" of the AP setup, I kept getting > > >radius response on MAC authentication, and EAP authentication does not > > >seem to happen. So, I thought it could be the certificate issue or the AP > > >just ignore the EAP authentication because MAC authentication is also > > >checked. > > > > > > Next what I do is to uncheck MAC authentication and leave only EAP > > >authentication, and use the test certificate Huge posted so that it > > >eliminates the possibility of the problem that is due to certificate > > >generation. With that, radius does not even get the rquest response. A > > >minor side note, I did make sure to use the right certificate in the XP > > >machine. So, if assuming the screen shot Mike sent me is complete, the > > >only possible conclusion left is the XP side. But as of now, I could not > > >find any document addressing similar problems. John's posting is as close > > >to my problem as I can find. > > > > > > Anyone out there has any insights? Thanks in advance! > > > > > >Bon > > > > > > > > >On Fri, 7 Mar 2003, Christian Wiedmann wrote: > > > > > > > > > > > >>Your settings sound fine. I have PEAP authentication working with the same > > >>setup on XP Home (SP1). I don't think that it matters whether the authenticate > > >>as computer or authenticate as guest boxes are checked (except that obviously > > >>it's going to fail to authenticate if you don't have them configured in > > >>Radiator). > > >> > > >>Are you sure you're getting a TLS tunnel? The TLS tunnel isn't established > > >>until the first identity exchange, which normally only happens after you enter > > >>information in the login window. If you actually are getting to the TLS stage, > > >>Windows must have credentials from somewhere - double check the MSCHAP-V2 > > >>settings to make sure it isn't using your Windows login information. > > >> > > >>What AP are you using? If it is a Linksys WRT51AB or similar, I've discovered > > >>that the AP requires a State attribute to be in the Radius replies. I've > > >>modified my version of Radiator to add one. I'm not sure if there is a cfg- > > >>file way of doing this -- I actually modified the perl code. > > >> > > >> -Christian > > >> > > >>On Fri, 7 Mar 2003, John McFadden wrote: > > >> > > >> > > >> > > >>>Date: Fri, 07 Mar 2003 14:16:44 -0500 > > >>>From: John McFadden <[EMAIL PROTECTED]> > > >>>To: [EMAIL PROTECTED] > > >>>Subject: (RADIATOR) Anyone get EAP-PEAP on XP to work Radius? > > >>> > > >>>I installed lastest Service Pack on XP to get the built in 802.1x client > > >>>but can't seem to get it to > > >>>authenticate via Radius. It appears that I get a TLS tunnel but never > > >>>get a logon popup on XP. > > >>> > > >>>I believe it is some kind of setup issue on XP not Radiator so I just > > >>>would like to > > >>>verify my XP setup before getting into Radiator. > > >>> > > >>>I started the Wireless Zero Config service. > > >>> > > >>>I clicked on the applicable connection and it's property button. > > >>> > > >>>In the authentication tab (confirms the Wireless Zero Config installed > > >>>and running.) > > >>>-I clicked on Enable IEEE802.1x > > >>>-I selected Protected EAP (PEAP) > > >>>-I left off Authenticate as computer > > >>>-I left off Authenticate as guest > > >>> > > >>> > > >>>In the peap properties tabe. > > >>>-I left off validate server certficate - I assume not required for > > >>>EAP-PEAP? Is this my problem? > > >>>-I selected EAP-MSCHAPV2 as authentication method. > > >>> > > >>>In the EAP-MSCHAPV2 properities I left off the use Windows userid, > > >>>password and domain. > > >>> > > >>>Can someone comment confirm this setup should work? > > >>> > > >>> > > >>> > > >>>Thanks in advance. > > >>> > > >>>John McFadden > > >>> > > >>> > > >>> > > >>> > > >>>=== > > >>>Archive at http://www.open.com.au/archives/radiator/ > > >>>Announcements on [EMAIL PROTECTED] > > >>>To unsubscribe, email '[EMAIL PROTECTED]' with > > >>>'unsubscribe radiator' in the body of the message. > > >>> > > >>> > > >>> > > >>=== > > >>Archive at http://www.open.com.au/archives/radiator/ > > >>Announcements on [EMAIL PROTECTED] > > >>To unsubscribe, email '[EMAIL PROTECTED]' with > > >>'unsubscribe radiator' in the body of the message. > > >> > > >> > > >> > > > > > >=== > > >Archive at http://www.open.com.au/archives/radiator/ > > >Announcements on [EMAIL PROTECTED] > > >To unsubscribe, email '[EMAIL PROTECTED]' with > > >'unsubscribe radiator' in the body of the message. > > > > > > > > > > > > > -- > > ************************************************************************ > > Denis Pavani > > > > CINECA - Comunicazioni e Sistemi Distribuiti > > NOC - Network Operation Center > > > > phone:+39 0516171953 / fax:+39 0516132198 > > http://www.cineca.it > > ************************************************************************ > > "Siamo pagati per adattarci, improvvisare e raggiungere lo scopo" > > -- Gunny Highway > > > > > > > > >
# eap_tls.cfg # # Example Radiator configuration file. # This very simple file will allow you to get started with # EAP TLS authentication. # We suggest you start simple, prove to yourself that it # works and then develop a more complicated configuration. # # This example will authenticate from a standard users file in # the current directory. # It will accept requests from any client and try to handle request # for any realm. # And it will print out what its doing in great detail. # # In order to authenticate, the clients user name must be in ./users # (the password is irrelevant for EAP TLS). # It will also require that the certificate installed on the client # is within one step of the root certificate, and that the subject name # in the client certificate is the same as the user name they are trying # to log in as. # # In order to test this, you WILL need to install server certificates and # keys for Radiator to read, and you will have to create and # install client certificates for the client side to use. # # There is a helpful tutorial for testing EAP TLS with Aironet wireless cards # on Linux at http://www.missl.cs.umd.edu/wireless/eaptls/ # other references for other OSs at http://www.denobula.com/EAPTLS.pdf and # You can debug EAP on an Aironet AP by telnetting and then :eap_diag1_on or :eap_diag2_on # # The example below is configured to work with the example test certificates # mentioned in http://www.missl.cs.umd.edu/wireless/eaptls/, which were # installed in /home/mikem/os/linux/cert. The configuration # may be different for your system. # # See radius.cfg for more complete examples of features and # syntax, and refer to the reference manual for a complete description # of all the features and syntax. # # Requires Net_SSLeay.pm-1.15 plus patches or later # Requires openssl 0.9.8 or later # See example in goodies/eap_tls.cfg # # You should consider this file to be a starting point only # $Id: eap_tls.cfg,v 1.2 2002/06/17 06:20:39 mikem Exp $ Foreground LogStdout LogDir . DbDir . # User a lower trace level in production systems: Trace 4 # You will probably want to add other Clients to suit your site, # one for each NAS you want to work with <Client DEFAULT> Secret nosecret DupInterval 0 </Client> <Realm DEFAULT> <AuthBy FILE> # Users must be in this file to get anywhere Filename /usr/local/etc/bon_users # EAPType sets the default EAP type that Radiator will # ask for when it receives an identity request # Options are: MD5-Challenge, One-Time-Password # Generic-Token, TLS. EAPType TLS # EAPTLS_CAFile is the name of a file of CA certificates # in PEM format. The file can contain several CA certificates # Radiator will first look in EAPTLS_CAFile then in # EAPTLS_CAPath, so there usually is no need to set both # EAPTLS_CAFile /home/mikem/os/linux/certxp/demoCA/cacert.pem # EAPTLS_CAPath is the name of a directory containing CA # certificates in PEM format. The files each contain one # CA certificate. The files are looked up by the CA # subject name hash value EAPTLS_CAPath /usr/local/qcwirelessCA/certs/ # EAPTLS_CertificateFile is the name of a file containing # the servers certificate. EAPTLS_CertificateType # specifies the type of the file. Can be PEM or ASN1 # defaults to ASN1 # EAPTLS_CertificateFile /home/mikem/os/linux/certxp/cert-srv.pem EAPTLS_CertificateFile /usr/local/qcwirelessCA/certs/bonnet17.pem EAPTLS_CertificateType PEM # EAPTLS_PrivateKeyFile is the name of the file containing # the servers private key. It is sometimes in the same file # as the server certificate (EAPTLS_CertificateFile) # If the private key is encrypted (usually the case) # then EAPTLS_PrivateKeyPassword is the key to descrypt it # EAPTLS_PrivateKeyFile /home/mikem/os/linux/certxp/cert-srv.pem # EAPTLS_PrivateKeyPassword whatever EAPTLS_PrivateKeyFile /usr/local/qcwirelessCA/certs/bonnet17.pem EAPTLS_PrivateKeyPassword whatever # EAPTLS_RandomFile is an optional file containing # randdomness # EAPTLS_RandomFile /home/mikem/os/linux/cert/random EAPTLS_RandomFile /usr/local/qcwirelessCA/certs/random # EAPTLS_MaxFragmentSize sets the maximum TLS fragemt # size that will be replied by Radiator. It must be small # enough to fit in a single Radius request (ie less than 4096) # and still leave enough space for other attributes # Aironet APs seem to need a smaller MaxFragmentSize # (eg 1024) than the default of 2048 EAPTLS_MaxFragmentSize 1024 # EAPTLS_DHFile if set specifies the DH group file. It # may be required if you need to use ephemeral DH keys. # EAPTLS_DHFile /home/mikem/os/linux/cert/dh EAPTLS_DHFile /usr/local/qcwirelessCA/certs/DH </AuthBy> </Realm>
