The EAP Saga continues.

[Evan Vittitow]

Phil Mayers wrote:
> 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?
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>   
The thing is, method number 1 (EAP-TLS) makes more sense for my laptops.
Method number 2 (EAP-PEAP) makes more sense for guest laptops that are
not mine.

The FreeRadius CA wrapper scripts did not work for my distro, so I'm
having to run CA.pl and the various openssl generation programs by hand.

Is it possible for both methods of authentication to be acceptable?