Hi, I'm setting up a RADIUS server which among others has to be linked to PAM. One of my primary requirements is that is uses secure cryptography. The main question is: 1. Does the PAM Radius module support EAP-TTLS with an inner tunnel of PAP? I did some research and came accross http://lists.freeradius.org/pipermail/freeradius-users/2013-December/069408...., which unfortunately doesn't answer my question. I scanned through the sourcecode of the PAM_radius module, which does not have any indication of TLS support. Background: Most supported protocols are based on MD5, which has been severly comprimised[1], or a single DES key (MSCHAP V2) [2], which is also comprimised. So that only leaves the TLS based protocols, Based on [3] I assume I should use PAP for the inner tunnel, because this enables me to store hashed password (will use SSHA512). If you know a more secure setup, don't hesitate to advice me :). Also if I made a mistake somewhere, don't hesitate to correct me :) As a final remark, I think it would be beneficial for the security of many account details, both transfered and stored for (FREE)RADIUS, to include clear warnings on the pages about insecure protocols/authentication standards. [1] https://en.wikipedia.org/wiki/MD5 [2] https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ [3] http://deployingradius.com/documents/protocols/compatibility.html
On Aug 21, 2015, at 5:29 AM, Qrious <Qrious@semtexgaming.com> wrote:
I'm setting up a RADIUS server which among others has to be linked to PAM. One of my primary requirements is that is uses secure cryptography. The main question is:
1. Does the PAM Radius module support EAP-TTLS with an inner tunnel of PAP?
No.
Most supported protocols are based on MD5, which has been severly comprimised[1], or a single DES key (MSCHAP V2) [2], which is also comprimised. So that only leaves the TLS based protocols,
That's a simplistic approach. Relying on buzzwords is no substitute for understanding. The truth is that the use of MD5 in RADIUS has no known security problems. So your worries are unfounded.
If you know a more secure setup, don't hesitate to advice me :). Also if I made a mistake somewhere, don't hesitate to correct me :)
Use RADIUS the way it was designed. The people who've spent 20 years working with it are competent.
As a final remark, I think it would be beneficial for the security of many account details, both transfered and stored for (FREE)RADIUS, to include clear warnings on the pages about insecure protocols/authentication standards.
No. Because there are no security problems. Honestly, do you think in 2015 that we'd be recommending the use of protocols which were broken and insecure? Even Microsoft doesn't do that any more. Alan DeKok.
Hi, First i'll reply to your comments:
Use RADIUS the way it was designed. The people who've spent 20 years working with it are competent.
I never said that were not competent. I was only refering to the fact that time changes perspective on security standards, as hardware and theoretical knowledge advance. Mainly because of this, I want to select strong modern cryptography now, to ensure it's security for the first decade.
Honestly, do you think in 2015 that we'd be recommending the use of protocols which were broken and insecure? Even Microsoft doesn't do that any more.
I hoped not (as my research showed), but fact is that cryptography is a complex field. Still there are a lot of services that (only) use insecure encryption, but that is an entirely other topic. I looked some further into the protocol. Because other people might stumble onto this thread, i'll give links to some useful resources. A good resource (although 13 years old) is: https://msdn.microsoft.com/en-us/library/bb742489.aspx (Why do you always find the useful resources after you really needed them?) Based on some slides of a guest lecture of an Eduroam engineer (which I can not share): User-Password = password XOR MD5(RequestAuth + Secret) (for passwords of length up to 16 - chaining procedure for longer passwords) 2015-08-21 12:21 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On Aug 21, 2015, at 5:29 AM, Qrious <Qrious@semtexgaming.com> wrote:
I'm setting up a RADIUS server which among others has to be linked to PAM. One of my primary requirements is that is uses secure cryptography. The main question is:
1. Does the PAM Radius module support EAP-TTLS with an inner tunnel of PAP?
No.
Most supported protocols are based on MD5, which has been severly comprimised[1], or a single DES key (MSCHAP V2) [2], which is also comprimised. So that only leaves the TLS based protocols,
That's a simplistic approach. Relying on buzzwords is no substitute for understanding.
The truth is that the use of MD5 in RADIUS has no known security problems. So your worries are unfounded.
If you know a more secure setup, don't hesitate to advice me :). Also if I made a mistake somewhere, don't hesitate to correct me :)
Use RADIUS the way it was designed. The people who've spent 20 years working with it are competent.
As a final remark, I think it would be beneficial for the security of many account details, both transfered and stored for (FREE)RADIUS, to include clear warnings on the pages about insecure protocols/authentication standards.
No. Because there are no security problems.
Honestly, do you think in 2015 that we'd be recommending the use of protocols which were broken and insecure? Even Microsoft doesn't do that any more.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
My previous message was accidentally sent before I completed it, so to continue. First of all, I'd like to add that this is not an offense to anyone, I just want to be able to verify your claims that the usage of an insecure hashing/encryption method does not compromise the entire security of RADIUS. My endgoal is to have a central authentication system that is secure.
That's a simplistic approach. Relying on buzzwords is no substitute for understanding.
I wouldn't call DES/3DES/MD5 buzzwords, just the names of the relevant hashing and encryption algorithms. I have a background in computer science, so I do understand these algorithms. However my daily job is not that of security officer/expert. I was taught that the usage of these algorithms are reason for concern and should be avoided if possible. Could you please clarify (or give pointers to documentation that counters the statements below) why the usage of MD5 in RADIUS has no known security problems? Because I found resources that appear to indicate otherwise: - http://www.untruth.org/~josh/security/radius/radius-auth.html (Research from 2001) - http://www.blackhat.com/presentations/bh-asia-00/jeremy-dave/jeremy-dave-asi... Related: - https://www.ietf.org/rfc/rfc6614.txt and (related) https://en.wikipedia.org/wiki/Diameter_(protocol) (why would someone make this if RADIUS itself is secure?) - It should be noted that back in 2002 Microsoft already called the usage of EAP-(T)TLS or IPSEC for RADIUS traffic 'best practice' (see previously mentioned MSDN page). Thanks in advance. 2015-08-21 14:01 GMT+02:00 Qrious <Qrious@semtexgaming.com>:
Hi,
First i'll reply to your comments:
Use RADIUS the way it was designed. The people who've spent 20 years working with it are competent.
I never said that were not competent. I was only refering to the fact that time changes perspective on security standards, as hardware and theoretical knowledge advance. Mainly because of this, I want to select strong modern cryptography now, to ensure it's security for the first decade.
Honestly, do you think in 2015 that we'd be recommending the use of protocols which were broken and insecure? Even Microsoft doesn't do that any more.
I hoped not (as my research showed), but fact is that cryptography is a complex field. Still there are a lot of services that (only) use insecure encryption, but that is an entirely other topic.
I looked some further into the protocol. Because other people might stumble onto this thread, i'll give links to some useful resources.
A good resource (although 13 years old) is: https://msdn.microsoft.com/en-us/library/bb742489.aspx (Why do you always find the useful resources after you really needed them?)
Based on some slides of a guest lecture of an Eduroam engineer (which I can not share):
User-Password = password XOR MD5(RequestAuth + Secret) (for passwords of length up to 16 - chaining procedure for longer passwords)
2015-08-21 12:21 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On Aug 21, 2015, at 5:29 AM, Qrious <Qrious@semtexgaming.com> wrote:
I'm setting up a RADIUS server which among others has to be linked to PAM. One of my primary requirements is that is uses secure cryptography. The main question is:
1. Does the PAM Radius module support EAP-TTLS with an inner tunnel of PAP?
No.
Most supported protocols are based on MD5, which has been severly comprimised[1], or a single DES key (MSCHAP V2) [2], which is also comprimised. So that only leaves the TLS based protocols,
That's a simplistic approach. Relying on buzzwords is no substitute for understanding.
The truth is that the use of MD5 in RADIUS has no known security problems. So your worries are unfounded.
If you know a more secure setup, don't hesitate to advice me :). Also if I made a mistake somewhere, don't hesitate to correct me :)
Use RADIUS the way it was designed. The people who've spent 20 years working with it are competent.
As a final remark, I think it would be beneficial for the security of many account details, both transfered and stored for (FREE)RADIUS, to include clear warnings on the pages about insecure protocols/authentication standards.
No. Because there are no security problems.
Honestly, do you think in 2015 that we'd be recommending the use of protocols which were broken and insecure? Even Microsoft doesn't do that any more.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 21, 2015, at 9:08 AM, Qrious <Qrious@semtexgaming.com> wrote:
First of all, I'd like to add that this is not an offense to anyone, I just want to be able to verify your claims that the usage of an insecure hashing/encryption method does not compromise the entire security of RADIUS.
It helps to understand *what* is insecure about MD5. Some uses of MD5 are insecure, others are not.
My endgoal is to have a central authentication system that is secure.
Then stop arguing and just use RADIUS. Or, go read the various security papers (like I did) to see *why* RADIUS is fine.
That's a simplistic approach. Relying on buzzwords is no substitute for understanding.
I wouldn't call DES/3DES/MD5 buzzwords, just the names of the relevant hashing and encryption algorithms.
That's not the point. The point is you see a buzzword / catch phrase "MD5 is insecure", and you get worked up about it, instead of understanding the issues.
However my daily job is not that of security officer/expert.
My job *is* a RADIUS expert. Since you're not, I suggest you stop arguing about the topic.
I was taught that the usage of these algorithms are reason for concern and should be avoided if possible.
That's the simplistic explanation for average people. It's correct for most situations.
Could you please clarify (or give pointers to documentation that counters the statements below) why the usage of MD5 in RADIUS has no known security problems? Because I found resources that appear to indicate otherwise: - http://www.untruth.org/~josh/security/radius/radius-auth.html (Research from 2001) - http://www.blackhat.com/presentations/bh-asia-00/jeremy-dave/jeremy-dave-asi...
Those are all true, but aren't the complete picture. Since you're not a security expert, I suggest you don't understand the attacks, and you won't understand the explanations as to why those attacks aren't relevant for most RADIUS situations.
Related: - https://www.ietf.org/rfc/rfc6614.txt and (related) https://en.wikipedia.org/wiki/Diameter_(protocol) (why would someone make this if RADIUS itself is secure?)
Don't be a jackass. RADIUS is secure. BUT any competent security person knows that attacks grow over time. So... RADIUS is being made *more* secure. As with RFC 7360 (RADIUS over DTLS). Which I wrote. Just look up "dekok RFC" on google, and note that I have a bit of a clue about this.
- It should be noted that back in 2002 Microsoft already called the usage of EAP-(T)TLS or IPSEC for RADIUS traffic 'best practice' (see previously mentioned MSDN page).
Since you're so interested in EAP-TLS, I suggest you implement it for the PAM module. It's open source. Submit patches instead of complaining. Work to make the world better, instead of telling people with more decades more experience that they're wrong. The arrogance of that is a little offensive, TBH. Or, configure *YOUR NETWORK* so that the RADIUS traffic runs over IPSec. You can do this yourself today. There's no need to complain about RADIUS security. Alan DEKok.
Hi,
insecure hashing/encryption method does not compromise the entire security of RADIUS.
incorrectly/poorly configured CLIENTS can comprise the entire security of RADIUS. if you are tunneling the credentials through a link using eg TLS 1.2, using a private CA and the client is configured to ONLY trust that CA (and not soem public one) and trust the CN (and not just any server cert from that CA) then you have a solid target to attack. MSCHAPv2 etc have their issues - but when you have no alternatives presented then having them wrapped up in the correct TLS tunnel is the answer.
- https://www.ietf.org/rfc/rfc6614.txt and (related) https://en.wikipedia.org/wiki/Diameter_(protocol) (why would someone make this if RADIUS itself is secure?)
actually its because they (Diameter folk) are crazy ;-)
- It should be noted that back in 2002 Microsoft already called the usage of EAP-(T)TLS or IPSEC for RADIUS traffic 'best practice' (see previously mentioned MSDN page).
ah, Microsoft who have ensured their RADIUS platform supports RADSEC...oh..no..wait a minute :/ alan
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Qrious