The EAP Saga continues.

[Phil Mayers]

Evan Vittitow wrote:
> Let me re-phrase, as I think I'm not quite making sense.
> 
> openssl req -new -keyout kurama.pem -out kurama.pem -days 730
> openssl x509 -in kurama.pem -out kurama.crt
> 
> openssl req -new -keyout altanis.pem -out altanis.pem -days 730
> openssl x509 -in altanis.pem -out altanis.crt
> 
> openssl req -new -keyout serenity.pem -out serenity.pem -days 730
> openssl x509 -in serenity.pem -out serenity.crt

Those are invalid openssl commands. The "req" subcommand generated a CSR 
(certificate signing request). One cannot turn a CSR into a CRT with the 
x509 command - you need to use the "openssl ca" commands for that.

FreeRadius comes with wrapper scripts for this. I suggest you extend 
them to generate the certs.

> 
> 
> Here are my three laptops, now as far as I know, based on my
> understanding of how EAP works, as long as the laptops have these certs,
> they should be able to authenticate users. the certs authenticate the nodes

To quote yourself, you're "not quite making sense".

An 802.1x supplicant communicates with the radius server (via the access 
point / switch) using EAP.

EAP negotiates ONE mechanism common to the supplicant and server, then 
executes that mechanism to mutually authenticate the client and the server.

So, for a given session your supplicants can either use EAP-TLS or PEAP. 
Whether they use credentials from a per-machine or per-user store is 
frankly irrelevant.

If you choose to use EAP-TLS, you need 4 items:

  1. A server certificate, signed by a Cert Authority "serverCA"
  2. A CA certificate ON THE SERVER for "clientCA", so the server can 
validate and trust the client certs.

  3. A client certificate, signed by a Cert Authority "clientCA"
  4. A CA certificate ON THE CLIENT for "serverCA", so the client can 
validate and trust the server certs.

You can (and usually do) have serverCA == clientCA so items 2 and 4 are 
the same.

If you choose to use EAP-PEAP/MS-CHAPv2 you need 4 items:

  1. A server certificate, signed by a Cert Authority "serverCA"
  2. At the server, the ability to execute the MS-CHAP algorith for the 
user - i.e. access to either the plaintext password, the NT/LM hashes, 
or the ntlm_auth helper binary and a copy of Samba joined to an NT domain

  3. At the client, a valid username/password
  4. A CA certificate ON THE CLIENT for "serverCA", so the client can 
validate and trust the server certs.

Item 3 (valid username/password) can either by a person account or it 
can be a machine account (username=netbiosname$, 
password=longrandomstring) if the machine is joined into an NT domain.

You can ALSO in theory use a client certificate with PEAP, but frankly 
it's more trouble than it is worth unless you have specialist requirements.


So - what are you trying to do?