stefan/list,
I am not sure this is a freeradius thing, but maybe others have similar questions/issues.
there are obviously different kinds of encryption and as you mention with out a key, decryption
is not possible. that leaves public key based encryption. so, poptop can do ssl based encryption,
can that be utilized to encrypt the transport in much the same way https encrypts http traffic?
the other thing that I am wondering is where the encryption/decryption takes place. I am keeping
my radius server on the pptpd server. so I do not care if the stream from pptpd to the freeradius
server is encrypted. so, when I connect, I encrypt at my client and then the pptpd calls the
freeradius plugin for authentication. does anyone know if pptpd decrypts before it passes the string to freeradius for authentication? or does it just pass on the encrypted stream and thus tries
to compare the mschapv2 encrypted stream with a md5 encrypted unix password? which lead to alan's response of "it won't work and never will".
if I am a user/admin that is concerned about security and manageablity am I stuck in the market
for a contivity vpn server ($$) that offers encrypted transport since it has its own client and can
thus handle the key management via that same $$?
thanks, cb
From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem authenticating to passwd/shadow files Date: Wed, 20 Oct 2004 17:42:20 +0100
Hi,
> 2. what is the best way to have encrypted transport > and encrypted passwords?
It depends on what you mean by encryption. Of course you can encrypt stuff by some symmetric encryption method and store the key to get the cleartext from the encrypted text somewhere (e.g. radius secrets), but that essentially means the password is protected just by another password which is somewhat pointless.
So, the term "encrypted" password as its used in normal conversation is just missleading. It normally really means "something which allows you to check correctness of the password, but doesn't allow you to get back to the password, no matter what". Typically, it's a hashed password or a challenge-response protocol or something similar, _not_ an enrypted password.
In that sense, you can have _either_ encrypted transport (i.e. the server sends a challenge and the client encrypts the challenge using the password as encryption key), then the server needs to know the password to verify the correctness ((MS-)CHAP protocols). _Or_ you can transfer the password ("unencrypted" transport) and let the server check that it can be hashed to the correct value (PAP-protocol).
However, you cannot avoid the need to _either_ actually transfer the password in every authentication _or_ have the server always know the password.
Of course, if you decide to transfer the password, you can add some protection such that not everybody sniffing the conversation can immediately read it (that's what the radius secret is used for in the conversation between AP and radius server, conversation between client and AP is the more vulnerable part, though).
And just the same, if you decide to store in on the server, you can add some protection such that not everybody sniffing on your local network can easily read it (e.g. putting it on a local disk instead of transporting it via NFS/Samba/whatever or putting it in an encrypted file or putting it in a file readable by root only and what ever else you can come up with).
Regards, Stefan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
