Walter Reynolds <waltr@umich.edu> wrote:

What I am trying to figure out is a way to not only have a certificate, but a secondary way to verify that that certificate is being used by a person we allow.

Passwords.

Is this something that can be done? Has anyone run into a similar problem and what did they do? I know we could go TTLS and not have a machine cert, but then we get fears of man-in-the-middle.

I would suggest a self-signed server cert, and a client certificate. You can use EAP-TLS-Require-Client-Cert to force a particular session to require a client cert. This works for TTLS, too. The server will then verify that the client cert is signed by the cert it has, which should prevent man in the middle attacks. Alan DeKok.

<------------------------------ < <Message: 4 <Date: Tue, 18 Apr 2006 18:10:58 +0100 <From: A.L.M.Buxey@lboro.ac.uk <Subject: Re: Can you use TLS and Request users authentication as well <To: FreeRadius users mailing list < <freeradius-users@lists.freeradius.org> <Message-ID: <20060418171058.GB16208@lboro.ac.uk> <Content-Type: text/plain; charset=us-ascii < <Hi, < <> that the cert was trusted. The problem is coming from a university, we <do <> not have a way to control a users machine. So a user could take that <> certificate and put it onto a friends machine. This friend may not be < <if the certificate (pkcs12 file) was password protected, then that <password <would have to be enetered before it could be installed onto a windows <machine <certificate store...or onto a MacOSX keychain...or used with Linux <supplicant. I knwo this. But what prevents a user from just giving this password to another. We are unable to manually put the certs on the machines, so we were looking at a web based certificate generation script. Maybe we can set it up so the password is not generated by the used, but by the script, the the installer woul dknow it, but not the user. < <> Is this something that can be done? Has anyone run into a similar <problem <> and what did they do? I know we could go TTLS and not have a machine <> cert, but then we get fears of man-in-the-middle. < <surely you'd have your systems certificate put onto the hosts...so when <they <associate to the network via TTLS then, if the cert doesnt match they get <a <nice warning (or no connection at all depending on config). teach the <users <never to ignore warnings (though we've all now had to suffer snakeoil <certs <on local secure http servers, out of date SSL certs on public hot spots <etc ;-) Maybe i need clarification. With TLS, the user machine is checked based on its requirement for a cert. The server is checked by its cert as well. Does the server cert have to be signed by the same server that signed the supplicants cert? And what if a public service (Verisign, Entrust.....) was used. If a supplicant tried to connect it would have the root ca in its keystore so no warning would be there. And what about using the built in Mac supplicant. I see no way to input the servers cert anyway. What am I missing? < <alan < < <------------------------------ < <Message: 5 <Date: Tue, 18 Apr 2006 13:07:10 -0400 <From: "Alan DeKok" <aland@nitros9.org> <Subject: Re: Can you use TLS and Request users authentication as well <To: FreeRadius users mailing list < <freeradius-users@lists.freeradius.org> <Message-ID: <20060418170710.8247216CC1@mail.nitros9.org> < <Walter Reynolds <waltr@umich.edu> wrote: <> What I am trying to figure out is a way to not only have a certificate, <> but a secondary way to verify that that certificate is being used by a <> person we allow. < < Passwords. I assume you mean on the cert as mentioned above. If so I responded there. If not what are you referring to? < <> Is this something that can be done? Has anyone run into a similar <problem <> and what did they do? I know we could go TTLS and not have a machine <> cert, but then we get fears of man-in-the-middle. < < I would suggest a self-signed server cert, and a client certificate. <You can use EAP-TLS-Require-Client-Cert to force a particular session <to require a client cert. This works for TTLS, too. < I did not know you could require a client cert on TTLS. This may work, but the probem then arises of Supplicants. I really shoudl say support of supplicants. This would require us to use 3rd party supplicant on Windows. We would like to avoid that far various reasons. < The server will then verify that the client cert is signed by the <cert it has, which should prevent man in the middle attacks. < < Alan DeKok. < <------------------------------

On Tue, 18 Apr 2006, Walter Reynolds wrote:

Hi,

What I am trying to figure out is a way to not only have a certificate, but a secondary way to verify that that certificate is being used by a person we allow. If we put cert onto a machine, we have authenticated that the cert was trusted. The problem is coming from a university, we do not have a way to control a users machine. So a user could take that certificate and put it onto a friends machine. This friend may not be affiliated and should not have access. So I would like to use the cert as machine authentication and then follow up with another (username/pass) using the KRB module.

Is this something that can be done? Has anyone run into a similar problem and what did they do? I know we could go TTLS and not have a machine cert, but then we get fears of man-in-the-middle.

Thanks.

-- Walter Reynolds University of Michigan

-- Walter Reynolds University of Michigan

From the changelog:

* Added "suppress" configuration entry to rlm_detail, to suppress certain attributes (e.g. User-Password). This closes bug #359. So how do I actually suppress the user password from the detail log based on this? Looking at the rlm_detail file and I might as well be looking at a foreign language. Thanks. -- Walter Reynolds University of Michigan