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 [sam...@open.com.au] > Sent: Thursday, October 01, 2015 10:49 PM > To: Nadav Hod; radiator@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 <sam...@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 <sam...@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. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
