Hello Nadav,
I don't want to control the discussion too much, but since this is
public list I think that I need to clarify couple of things.
1. Certificates are public information. They are sent in clear text over
network for example during EAP-TLS/TTLS/PEAP conversation. So you don't
need to protect them.
What you need to protect is the sever private key.
If you have defined password for private key it means that it is
encrypted. In order to use it, you need to provide the password in order
to decrypt the private key.
If you want that process can start automatically you need to have access
to the private key encryption password.
I agree with Nick that external chip is the only way to provide strong
protection for the private key.
2. Radiator support hashed and encrypted user passwords.
For example if you are authenticating users from file, you can have
there for example:
User-Password={SSHA512}<hash> or User-Password={PBKDF2}
please see more in section 13.1.2 in reference manual.
Hashed passwords does not work with all authentication methods. For
example MSCHAPv2 that is used with PEAP requires to have access to clear
text or nt-hash format of password.
3. NAS shared secrets
It is possible to include NAS clients to SQL or LDAP database and use
their encryption mechanisms to protect shared secrets. Again you need to
define encryption key somewhere if you want Radiator to run autonomously.
NAS shared secrets are not user passwords. If you are using plain PAP
authentication it is used to protect User-Password but the protection is
not very strong. When you are using EAP-TLS/TTLS/PEAP then the TLS
tunnel is protecting user credentials and it offers much better protection.
Radiator supports also RADSEC that moves RADIUS traffic over TLS tunnel
and then you will get good protection for messages and you don't need to
define shared secrets since certificates are used.
Best Regards,
Sami
On 10/01/2015 04:36 PM, Nadav Hod wrote:
> Hi Nick,
>
> Specific hardware for securing files on your server shouldn't be necessary
> for the use cases I'm suggesting. I've just integrated Radiator for the first
> time and I was shocked that for each NAS I had to keep the password in
> plaintext.
> Radiator is installed on servers worldwide whether physical or VM, I believe
> that each of them (regardless of hardware) should be provided with at least
> the same security as NPS which knows how to accept user passwords in
> plaintext and then obfuscate them (whether encrypted, hashed or otherwise).
>
> A solution can be integrated via software, and my suggestions use perl and
> openssl to secure sensitive information. Therefore only integration is
> necessary without new environments.
> ________________________________________
> From: Nick Lowe [nick.l...@lugatech.com]
> Sent: Thursday, October 01, 2015 4:23 PM
> To: Nadav Hod
> Cc: radiator@open.com.au
> Subject: Re: [RADIATOR] Password/certificate security seems next to none on
> Radiator server
>
> If you wanted robust protection here, you would likely want to go down
> the route of a TPM or equivalent.
>
> Nick
> _______________________________________________
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
--
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
