[RADIATOR] Password/certificate security seems next to none on Radiator server

[Sami Keski-Kasari]

Hello Nadav,

When using EAP-TLS:
In supplicant side you need to have supplicant's private key and
certificate.
In server side you have private key and certificate.

Those keys and certificates are used to do the authentication.
During authentication it is verified that you have the private key for
certificate you are presenting to the peer.

CA brings a way to provide trust relationship between supplicant and
server so that for example you don't need to introduce all client
certificates to Radiator. When using CA you can for example just tell
that trust all certificates that has been signed with private key of
this CA.

But again the CA private key is what you need to protect. CA certificate
is public information and it can be used only for verification purposes,
not for signing any certificates.

CA's private key private should stay in the CA and you don't need that
in Radiator either. Only private key you need in Radiator is the
server's private key.

Best Regards,
 Sami

On 10/02/2015 09:12 AM, Nadav Hod wrote:
> Regarding only private keys being sensitive:
> 
> For EAP-TLS I only need the Cisco CA and a server certificate with a private key. The cisco CA had no trust relation with my domain which created the server certificate and private key for the server. So there was no shared CA between supplicant and authentication server.
> 
> In this case the private key wasn't necessary to authenticate the phones. ACS, Cisco's AAA server, also doesn't require the CAPF private key but rather the CAPF public key to authenticate phones. 
> 
> ________________________________________
> From: Sami Keski-Kasari [samikk at open.com.au]
> Sent: Thursday, October 01, 2015 10:49 PM
> To: Nadav Hod; radiator at open.com.au
> Subject: Re: [RADIATOR] Password/certificate security seems next to none on Radiator server
> 
> Hello Nadav,
> 
> On 10/01/2015 08:52 PM, Nadav Hod wrote:
> 
>> And keep in mind that not just private keys need to be kept secure.
>> To authenticate phones with EAP-TLS I needed the Cisco call manager's
>> CA to be stored locally on Radiator. The certificate was self-signed
> and not
>> exportable without a cisco admin account. If anyone else were to have
> access
>> to that certificate they could impersonate my server. Same goes for
> any other
>> supplicant with a CA which isn't made public.
> 
> In public key cryptography only private key is needed to be kept secure.
> For example certificate is a public key that you can give to anyone in
> order to verify you.
> 
> CA is signing certificates with it's private key and CA certificate is
> used to validate certificates CA has signed.
> So it is not possible to impersonate your server with CA certificate.
> CA's private key is needed to do that.
> 
> Best Regards,
>  Sami
> 
> --
> Sami Keski-Kasari <samikk at open.com.au>
> 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
> NetWare etc.
> 


-- 
Sami Keski-Kasari <samikk at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.