I ma trying to set up freeRADIUS server implementing (wireless) user authentication (running wpa_supplicant) via AP (running hostapd). After reading various howto's and documentation as well as looking at numerous sources on the Internet, I can't see a way in which the AP is authenticated to the RADIUS server by using only its certificate attributes (CN, Subject, Issuer etc) - it seems that freeRADIUS always needs some sort of "password" or "shared secret" specified. Is it possible *not* to use this and rely solely on the strength/culpability (depending on the way one looks at it) of PKI? If so, how do I achieve that? A very simple configuration file example would suffice! In relation to that - another question: the rlm_eap text file (in the doc/ directory) distributed with the source code (I am using 2.1.12) states that "Currently Freeradius supports only 2 EAP-Types (EAP-MD5, EAP-TLS)." (line 78). Is that so? As for the actual EAP-TTLS/EAP-TLS authentication process I have another query - my understanding of the theory behind this method is that the authentication/authorisation process is done in two distinct phases - outer and inner authentication. This also allows for the use of two distinct sets of (client, server, ca) certificates to be specified in each phase. If that is so, how is this configured/specified in the eap.conf configuration file (or elsewhere)? Many thanks!
Am 26.11.2011 22:04, schrieb Mr Dash Four:
I ma trying to set up freeRADIUS server implementing (wireless) user authentication (running wpa_supplicant) via AP (running hostapd).
After reading various howto's and documentation as well as looking at numerous sources on the Internet, I can't see a way in which the AP is authenticated to the RADIUS server by using only its certificate attributes (CN, Subject, Issuer etc) - it seems that freeRADIUS always needs some sort of "password" or "shared secret" specified.
so it is, you can only protect your AP client with the shared secret key.
Is it possible *not* to use this and rely solely on the strength/culpability (depending on the way one looks at it) of PKI? If so, how do I achieve that? A very simple configuration file example would suffice! In relation to that - another question: the rlm_eap text file (in the doc/ directory) distributed with the source code (I am using 2.1.12) states that "Currently Freeradius supports only 2 EAP-Types (EAP-MD5, EAP-TLS)." (line 78). Is that so?
As for the actual EAP-TTLS/EAP-TLS authentication process I have another query - my understanding of the theory behind this method is that the authentication/authorisation process is done in two distinct phases - outer and inner authentication. This also allows for the use of two distinct sets of (client, server, ca) certificates to be specified in each phase. If that is so, how is this configured/specified in the eap.conf configuration file (or elsewhere)?
Many thanks! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQGNBE6jHfABDACyzFkn6k+OtbRANjKZ6NEQOxnnsBSBSs6sT9EBF0U3MnnYW3/p YTW+7aUa/1FZTOWt9wb9H7t0SOqpgqUBmRo/sPteepXblnDaGEh8tzIWfaC9MKc1 QobU5zK9KcDKrs3SyGXEPOOQM8QdtE8KfSJFdUxfanFJUbfTbxq5Gqz1eaU4cWxp gR6GeVYnd11J8AdDDwkjPjx4ZJ5guZ+D646Qi3CT7KT6y8sXVPwpNA3CvGweYX0r STKyBf+nlQtOtByrgZW7BiSAxilYUL4mGE4KmuYAadJ+O6X7NOtz3OQaWgSGjqxH YxDu6orTzL4/csjoVXS9dgeGkhLJgAg72a2yxA4tx/8IXrGp3JVGYGEY2kYcq3k9 jq5hJezoy6s1N//mgm5KaB84zrU5cUcu8kXDppmnp7eXUPnBqj2g2O82buBNa48S wAtnbY4K5fbcnog8g6ouYXpAJo9yHcj+wraQ8+TNFx5nbkg3fZKuf3UeyL3dPKXf wsKehnZ3Ipqkb08AEQEAAbQiQW5kcmVhcyBSdWRhdCA8cnVkYXRAZW5kc3RlbGxl LmRlPokBuAQTAQIAIgUCTqMd8AIbDwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA CgkQBw5gh+kRIv+yGQv5AQCRZt8wR2McgsTurZEZXz5UpxEPZB/dA/iXtPzZXJih XLRZFqcdT+c8DCLbhXjO5aLndOCIDwWmsnqX2fuGAjlM4GJAAUEARSNtWY7V+rUt PhdOz/flCZo/+p7wBi0XOJcWhysS7DV/ssSYdnuJvONUBXCQ/MpJsVXuKdgPa9IR hvi37Ang1Cxb7htKHIuA4wCuqz1/4VGNez/65qwjuYakbB4/rXkKWb17XqCZrtoo YiQSxPU7fP5lM4ybQXxP1qrptmaF9EqGTnj/xAU3tCE+PhB3baoVw6VG9nr9xYwh bqCGtTbtrkmYlgioC2fFHDgg3U1GVBIbi0AoddXSs5OekgSvt827OcyWVSyjobyn tH4/jwb8X8iOM/x8RZhzwKhpHA0k7ltTm7qXApARcL1tV6y4GIKwuy1RLZqkpNh1 teqYaxAKlxC77s6gftxqr7G6NCssgCCy2Y50LSvcQbZDPZeBdrPoGI/xAWNy4Otv 33k4P9hxJKHNqLYJN+Gn =UaS9 -----END PGP PUBLIC KEY BLOCK-----
After reading various howto's and documentation as well as looking at numerous sources on the Internet, I can't see a way in which the AP is authenticated to the RADIUS server by using only its certificate attributes (CN, Subject, Issuer etc) - it seems that freeRADIUS always needs some sort of "password" or "shared secret" specified.
so it is, you can only protect your AP client with the shared secret key.
In other words, EAP-TTLS/EAP-TLS isn't actually supported in freeRADIUS?
Mr Dash Four <mr.dash.four@googlemail.com> wrote:
After reading various howto's and documentation as well as looking at numerous sources on the Internet, I can't see a way in which the AP is authenticated to the RADIUS server by using only its certificate attributes (CN, Subject, Issuer etc) - it seems that freeRADIUS always needs some sort of "password" or "shared secret" specified.
so it is, you can only protect your AP client with the shared secret key.
In other words, EAP-TTLS/EAP-TLS isn't actually supported in freeRADIUS?
It is. I believe you misunderstood how RADIUS works. The connection between the AP (called NAS in RADIUS) and the RADIUS-Server is only protected by the shared secret configured in clients.conf. Yes, this is kind of weak. And because of this weakness a protocol like RADsec has been developed, which is essentially RADIUS-with-SSL-over-TCP, thus providing strong encryption of the whole RADIUS session. So far I have not seen any devices like APs, Dial-in-Servers, etc. support RADsec. But this is normally no problem, since those devices are usually located in a safe network with the RADIUS server. RADsec for example is used in the Deutsche Forschungsnetz (DFN), to secure inter-university RADIUS connections over the Internet to authenticate Eduroam users. Back to EAP-(T)TLS: The connection between a connecting device such as a laptop, which connects to a NAS, can be secured via EAP-(T)TLS, which is a protocol transported via RADIUS packets. This of course is supported by FreeRADIUS since ages. Grüße, Sven. -- Sigmentation fault. Core dumped.
Sven Hartge <sven@svenhartge.de> wrote:
Yes, this is kind of weak. And because of this weakness a protocol like RADsec has been developed, which is essentially RADIUS-with-SSL-over-TCP, thus providing strong encryption of the whole RADIUS session.
Addition: The first FreeRADIUS version to include native RADsec support will be 3.0. To use it with a version below that, you usually proxy your normal RADIUS request through a software like radsecproxy. But again: this is normally only used between RADIUS servers across a insecure network and not betweens a client (meaning an AP or a modem-server, etc.) and its RADIUS server. Grüße, Sven. -- Sigmentation fault. Core dumped.
Addition: The first FreeRADIUS version to include native RADsec support will be 3.0. To use it with a version below that, you usually proxy your normal RADIUS request through a software like radsecproxy.
Very interesting indeed. How about tunnelling (via ssh for example) - is that a similar technique?
But again: this is normally only used between RADIUS servers across a insecure network and not betweens a client (meaning an AP or a modem-server, etc.) and its RADIUS server.
If there is something I learned about such things, it is that when it comes to security issues one can *never* be too careful!
Mr Dash Four <mr.dash.four@googlemail.com> wrote:
Addition: The first FreeRADIUS version to include native RADsec support will be 3.0. To use it with a version below that, you usually proxy your normal RADIUS request through a software like radsecproxy.
Very interesting indeed. How about tunnelling (via ssh for example) - is that a similar technique?
Very unusual. Normally, you only control one of two RADIUS servers, one being the one in your network and the other one being located in some other organization. Of course you can create a tunnel between the two servers, but this would be custom, non-standard setup.
But again: this is normally only used between RADIUS servers across a insecure network and not betweens a client (meaning an AP or a modem-server, etc.) and its RADIUS server.
If there is something I learned about such things, it is that when it comes to security issues one can *never* be too careful!
Well, if you cannot trust your own internal network, then you have other problems than securing your RADIUS authentication. Grüße, Sven. -- Sigmentation fault. Core dumped.
Mr Dash Four wrote:
Networks, no matter how secure, can be compromised. As I pointed out previously - one can never be too careful.
You're not "smart" if you regurgitate trite phrases. You're smart if you spend the time to understand what you're talking about. You haven't done that. Alan DeKok.
Networks, no matter how secure, can be compromised. As I pointed out previously - one can never be too careful.
You're not "smart" if you regurgitate trite phrases.
And you are not "smart" either when you start throwing insults around.
You're smart if you spend the time to understand what you're talking about.
You haven't done that.
I know what I am talking about. When there is something I don't know, however - I ask, politely, and expect the same from others (that doesn't include you, apparently).
Hi,
You haven't done that.
You're smart if you spend the time to understand what you're talking I know what I am talking about. When there is something I don't know, however - I ask, politely, and expect the same from others (that doesn't include you, apparently).
I think what Alan was trying to point out is that it is easy to find answers to your basic questions without asking this mailing list. The security of RADIUS is incredibly well-documented, and not specific to FreeRADIUS. So if your problem is that you don't know whether or not a RADIUS shared secret is sent in clear text or not - and jump to false conclusions based on your *belief* how it *might* work (even if you are wrong in your assumptions) then that is typically called "noise" on a mailing list. You might rather want to clarify that aspect yourself. I just typed "RADIUS shared secret" into Google, and found actual on-topic results - on page one. Microsoft Technet unfortunately, but better than nothing. Now to get more down to the topic. You mention that security is paramount, which is correct. When you are using EAP-TLS or EAP-TTLS, security of your transmitted credentials comes by virtue of the TLS tunnel that is established within that EAP method. The transport-layer security of RADIUS adds nothing to the security of these credentials. In that case, it doesn't matter much - for security reasons - whether your Access Points talk RADIUS (IP+shared secret) or RADIUS/TLS. What *is* revealed if you use "only" RADIUS, is some of the not-so-significant attributes in the Access-Request like the MAC address of the connecting client in Calling-Station-Id. That you might possibly see as a rather minimal privacy invasion if an eavesdropper listens on the packet; in that case, RADIUS/TLS would be a way of mitigating that. Your thread contains lots of confusion, false assumptions and wrong conclusions. There is always a danger that that kind of "half-knowledge" spreads and leads to FUD. So to be abundantly clear: Transport security ------------------------- * traditional: fixed bindings of IP address+shared secret; uses MD5 for hash calculation * TLS security: either TLS-PSK (drop-in replacement for shared secret) or certificate based Credential security -------------------------- * most EAP types "roll their own", which makes transport security less relevant * EAP-TLS, TTLS, PEAP, FAST are among those * FreeRADIUS supports all of these EAP types just fine * some weak EAP types don't provide that security on their own, and either - need to be tunneled within TTLS and friends - or - - need to be secured by transport security I think this answers all the questions in your thread and counteracts all the conclusions you jumped onto mid-way. If I may add: almost none of these questions were specific to *FreeRADIUS - the product* - they were about the RADIUS protocol. This mailing list is not the place to ask random questions about RADIUS. Read up on it on the internet, buy a book, or visit a course about RADIUS. The mailing list is about configuring FreeRADIUS. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
I think what Alan was trying to point out is that
He's been unsubscribed from the list. It's OK to not understand RADIUS. It's OK to ask questions. It's OK to ask for help. That's what the list is for. It's *not* OK to say "I've only been doing RADIUS for 2 days", and then to imply he's made a brilliant discovery that everyone else missed.
it is easy to find answers to your basic questions without asking this mailing list. The security of RADIUS is incredibly well-documented, and not specific to FreeRADIUS. So if your problem is that you don't know whether or not a RADIUS shared secret is sent in clear text or not - and jump to false conclusions based on your *belief* how it *might* work (even if you are wrong in your assumptions) then that is typically called "noise" on a mailing list.
It's a psychological issue common among certain people. Because he knows nothing about RADIUS, he has no basis for judging who is a RADIUS expert, and who is a newbie. Therefore, he thinks he (a newbie) is just as much of an expert as people who've done it for 15 years. Normal people don't do that.
Your thread contains lots of confusion, false assumptions and wrong conclusions. There is always a danger that that kind of "half-knowledge" spreads and leads to FUD. So to be abundantly clear:
Exactly. The reason to answer is for later people. We don't want anyone else to be confused and misled by his false statements. Alan DeKok.
In other words, EAP-TTLS/EAP-TLS isn't actually supported in freeRADIUS?
It is. I believe you misunderstood how RADIUS works.
Maybe, considering I've been reading about RADIUS for just over 2 days...
The connection between the AP (called NAS in RADIUS) and the RADIUS-Server is only protected by the shared secret configured in clients.conf.
Yes, this is kind of weak. It is *very* weak, not least because connections can be intercepted as, I presume is the case here, this "shared secret" is transmitted in the clear over the wire. If that is not the case and it is hashed, then, that's another story.
And because of this weakness a protocol like RADsec has been developed, which is essentially RADIUS-with-SSL-over-TCP, thus providing strong encryption of the whole RADIUS session.
So far I have not seen any devices like APs, Dial-in-Servers, etc. support RADsec. But this is normally no problem, since those devices are usually located in a safe network with the RADIUS server.
RADsec for example is used in the Deutsche Forschungsnetz (DFN), to secure inter-university RADIUS connections over the Internet to authenticate Eduroam users.
Interesting, noted. It would be nice if this works in a similar way as the SSL handshake works - this is very secure, tested and already established in the real world.
Back to EAP-(T)TLS:
The connection between a connecting device such as a laptop, which connects to a NAS, can be secured via EAP-(T)TLS, which is a protocol transported via RADIUS packets.
This of course is supported by FreeRADIUS since ages.
OK, my understanding of EAP-TTLS/EAP-TLS is that the authentication happens in two distinct stages: the first stage (EAP-TTLS) is the outer authentication where the server presents its credentials/certificate to the client and then the secure channel is established. Phase two (EAP-TLS in my case) is where the client - via its client certificate - is actually authenticated to the RADIUS server. Now, I was hoping that the AP does this in a similar sort of way when authenticating itself to the RADIUS server, but it seems that is not the case and this is indeed a weak point. My question still remains though - since this is a two-phase authentication, two distinct sets of (ca, server, client) certificates can be used. How do I specify these in RADIUS? I found that I could specify the ca, client and server certificates once (normally stored in raddb/certs if memory serves), but I potentially need two of each for each phase. I know I could use just one, but just for the sake of understanding the whole process and getting to know how it all works I need to know this. How do I do that?
Mr Dash Four <mr.dash.four@googlemail.com> wrote:
In other words, EAP-TTLS/EAP-TLS isn't actually supported in freeRADIUS?
It is. I believe you misunderstood how RADIUS works.
Maybe, considering I've been reading about RADIUS for just over 2 days...
The connection between the AP (called NAS in RADIUS) and the RADIUS-Server is only protected by the shared secret configured in clients.conf.
Yes, this is kind of weak. It is *very* weak, not least because connections can be intercepted as, I presume is the case here, this "shared secret" is transmitted in the clear over the wire. If that is not the case and it is hashed, then, that's another story.
No, the shared secret is not transmitted over the wire. For additinal information see RFC2865, §2: "When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5. (see RFC131).
And because of this weakness a protocol like RADsec has been developed, which is essentially RADIUS-with-SSL-over-TCP, thus providing strong encryption of the whole RADIUS session.
Interesting, noted. It would be nice if this works in a similar way as the SSL handshake works - this is very secure, tested and already established in the real world.
RadSec works this way, yes. Think of it like HTTPS for RADIUS.
Back to EAP-(T)TLS:
The connection between a connecting device such as a laptop, which connects to a NAS, can be secured via EAP-(T)TLS, which is a protocol transported via RADIUS packets.
This of course is supported by FreeRADIUS since ages.
OK, my understanding of EAP-TTLS/EAP-TLS is that the authentication happens in two distinct stages: the first stage (EAP-TTLS) is the outer authentication where the server presents its credentials/certificate to the client and then the secure channel is established. Phase two (EAP-TLS in my case) is where the client - via its client certificate - is actually authenticated to the RADIUS server. Now, I was hoping that the AP does this in a similar sort of way when authenticating itself to the RADIUS server, but it seems that is not the case and this is indeed a weak point.
No, the AP does not authenticate itself to the RADIUS server via TLS, just via the shared secret configured in clients.conf.
My question still remains though - since this is a two-phase authentication, two distinct sets of (ca, server, client) certificates can be used. How do I specify these in RADIUS?
Which distinct set of certificates? The server certificate and key is configured via eap.conf. Which client certificates the RADIUS server trusts is configured via CA_file, also in eap.conf. Grüße, Sven. -- Sigmentation fault. Core dumped.
No, the shared secret is not transmitted over the wire.
For additinal information see RFC2865, §2:
"When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5. (see RFC131).
MD5 is broken.
My question still remains though - since this is a two-phase authentication, two distinct sets of (ca, server, client) certificates can be used. How do I specify these in RADIUS?
Which distinct set of certificates?
OK, for the first phase (EAP-TTLS) there is the CA certificate, server certificate/key and, optionally, the client certificate/key (fetched/presented on request if I configure this on the client side). For the second phase (EAP-TLS) - there is, again, the CA certificate, the client certificate/key (which is used to actually authenticate the client) and the server certificate/key. For this second phase the CA, server certificate/key as well as client certificate/key may be different (they can be configured to be different - at least that is how it is done on the client side with wpa_supplicant.conf). The question is - how do I specify the CA, CA2, server certificate/key and server certificate/key second pair (for phase two) in RADIUS?
The server certificate and key is configured via eap.conf.
As far as I can see in eap.conf I can only configure *one* CA (CA_file) and one server certificate/key ("certificate_file", "private_key_file" & "private_key_password" options) - all via "tls {}". So, there is no room for one of the phases - unless I am missing something obvious. If I want to use a different CA_file and different server certificate/key for the other phase how do I do that in RADIUS? To illustrate my point a bit more clearly - in wpa_supplicant.conf (on the client side) I can specify the following parameters with regards to EAP-TTLS/EAP-TLS: proto=WPA2 key_mgmt=WPA-EAP auth_alg=OPEN eap=TTLS # Phase 1 / outer authentication ca_cert="/etc/cert/ca_p1.pem" subject_match="/C=US/ST=CA/L=San Francisco/CN=Test AS/emailAddress=ap_server@example.com" altsubject_match="EMAIL:ap_server@example.com;DNS:dns.example.com;DNS:dns2.example.com" client_cert="/etc/cer/user_p1.pem" private_key="/etc/cer/user_p1.key" private_key_passwd="password" # Phase 2 / inner authentication phase2="autheap=TLS" ca_cert2="/etc/cert/ca_p2.pem" subject_match2="/C=US/ST=CA/L=San Francisco/CN=Test2 AS/emailAddress=ap_server2@example.com" altsubject_match2="EMAIL:ap_server2@example.com;DNS:dns.example.com;DNS:dns2.example.com" client_cert2="/etc/cer/user_p2.pem" private_key2="/etc/cer/user_p2.key" private_key2_passwd="password2" So, on the client side I could configure two sets of the keys/certificates required. How do I do that with RADIUS? Also, how do I actually configure/specify the user authentication certificate? I need to be able to authenticate user by the various certificate attributes (CN, Subject etc) - in both phases!
On 11/27/2011 12:51 AM, Mr Dash Four wrote:
No, the shared secret is not transmitted over the wire. For additinal information see RFC2865, §2:
"When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5. (see RFC131). MD5 is broken.
Thanks for the public service announcement. Do you seriously think the IETF, and the people responsible for RADIUS protocol evolution, aren't aware of this? Seriously, what would you like us to do exactly? Travel back in time to the mid 1990s and re-do the first RADIUS implementations with end-to-end pluggable crypto, and at the same time arrange for the Wassenaar agreement to be revoked? If you want better security than that provided by the shared secret, you're free to arrange it between your NAS and your radius server. Some places use IPSec for this purpose, or things like OpenVPN. HOWEVER - before you do that, and before you make any more announcements on how insecure RADIUS is, perhaps you could actually put some time and effort into understanding the protocol. You are missing two critical bits of info: Firstly, all radius packets carrying EAP MUST carry a Message-Authenticator attribute. This provides secure integrity proof (and thus authentication) of the ENTIRE packet payload, using a HMAC and the shared secret as a key. Many NASes support this attribute on all packets (not just EAP), and FreeRADIUS supports a configuration option to MANDATE the presence of this attribute in requests from client NASes. Secondly, although radius packets are not encrypted, the payload data in EAP methods is. Put another way - EAP confidentiality and integrity is provided *by the EAP mechanisms*, not by the radius layer. For pre-EAP mechanisms, the shared secret encryption will encrypt some fields (e.g. User-Password, in PAP), and the remaining mechanisms tend to be challenge/response, with their own security properties. When using Message-Authenticator (which, as required by RFCs, is the case for ALL EAP-over-RADIUS) the only meaningful "security problem" is a mild information leak of some NAS-related metadata (NAS-Port, etc.) in the packet. The rest of the information (EAP payload, Calling/Called-Station-Id, outer User-Name) are all sent in the clear by the client anyway, often over Wi-Fi. Is the shared secret ideal? No. Is RADSEC better? Yes. Do any NAS vendors support it? No. Can we afford to stop using RADIUS? No.
The question is - how do I specify the CA, CA2, server certificate/key and server certificate/key second pair (for phase two) in RADIUS?
Specify two different instances of the eap module. There is an example of this in the default configs in recent 2.1.x versions - see raddb/modules/inner-eap. Once you've done that, use the 2nd module inside your inner-tunnel, like so: eap { tls { ... cert setup } ttls { ... virtual-server = inner-tunne } } eap eap-inner { tls { ... 2nd ca setup } } ...then: sites-available/default: authorize { ... eap ... } authenticate { ... eap } sites-available/inner-tunnel: server inner-tunnel { authorize { ... eap-inner ... } authenticate { ... eap-inner } }
Hi,
Firstly, all radius packets carrying EAP MUST carry a
<snip> thanks Phil for this concise overview..however....
Is the shared secret ideal? No. Is RADSEC better? Yes. Do any NAS vendors support it? No. Can we afford to stop using RADIUS? No.
LANCOM do eg http://www.lancom.eu/fileadmin/produkte/lc_l54/L-54g_EN.pdf you can blame Stefan Winter for this... ;-) alan
Am 27.11.2011 10:17, schrieb Phil Mayers:
On 11/27/2011 12:51 AM, Mr Dash Four wrote:
No, the shared secret is not transmitted over the wire. For additinal information see RFC2865, §2:
"When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5. (see RFC131). MD5 is broken.
but I understand it correctly, the shared_secret is just using as trusted "AP" password?
Thanks
MD5 is broken.
Thanks for the public service announcement. Pleasure!
Do you seriously think the IETF, and the people responsible for RADIUS protocol evolution, aren't aware of this?
Seriously, what would you like us to do exactly? Travel back in time to the mid 1990s and re-do the first RADIUS implementations with end-to-end pluggable crypto, and at the same time arrange for the Wassenaar agreement to be revoked?
If you want better security than that provided by the shared secret, you're free to arrange it between your NAS and your radius server. Some places use IPSec for this purpose, or things like OpenVPN. Up until yesterday, I wasn't aware that the only way AP/NAS can communicate with the RADIUS is via unencrypted channel. That's fair enough, I suppose, once I know what I am up against I will take the appropriate actions/measures to mitigate the possible security implications and reduce the risks, if I can. I wasn't making a "public announcement", it was merely an observation - stop being so precious!
HOWEVER - before you do that, and before you make any more announcements on how insecure RADIUS is, perhaps you could actually put some time and effort into understanding the protocol. You are missing two critical bits of info:
[...]
Is the shared secret ideal? No. Is RADSEC better? Yes. Do any NAS vendors support it? No. Can we afford to stop using RADIUS? No. Thank you - if I knew where to look for this information, I would have done it ages ago.
The question is - how do I specify the CA, CA2, server certificate/key and server certificate/key second pair (for phase two) in RADIUS?
Specify two different instances of the eap module. There is an example of this in the default configs in recent 2.1.x versions - see raddb/modules/inner-eap. Once you've done that, use the 2nd module inside your inner-tunnel, like so: Thanks again, I wasn't aware that I could have inner/different instances. Apart from the various, rather scattered, files with sample configuration examples is there a more comprehensive manual which includes (and explains) all these options? I'd rather read those than relying on jamooks like DeCock to explain it all to me (or not, as it may be the case here)?
On 27 Nov 2011, at 00:40, Mr Dash Four wrote:
In other words, EAP-TTLS/EAP-TLS isn't actually supported in freeRADIUS?
It is. I believe you misunderstood how RADIUS works.
Maybe, considering I've been reading about RADIUS for just over 2 days...
Why don't you try reading about EAP and 802.1X too?
The connection between the AP (called NAS in RADIUS) and the RADIUS-Server is only protected by the shared secret configured in clients.conf. Yes, this is kind of weak. It is *very* weak, not least because connections can be intercepted as, I presume is the case here, this "shared secret" is transmitted in the clear over the wire. If that is not the case and it is hashed, then, that's another story.
No... and When would you ever send a shared secret over the wire in the clear? That negates the secret part...
And because of this weakness a protocol like RADsec has been developed, which is essentially RADIUS-with-SSL-over-TCP, thus providing strong encryption of the whole RADIUS session.
So far I have not seen any devices like APs, Dial-in-Servers, etc. support RADsec. But this is normally no problem, since those devices are usually located in a safe network with the RADIUS server.
RADsec for example is used in the Deutsche Forschungsnetz (DFN), to secure inter-university RADIUS connections over the Internet to authenticate Eduroam users.
Interesting, noted. It would be nice if this works in a similar way as the SSL handshake works - this is very secure, tested and already established in the real world.
Of course it does, it's using TLS... You think the RADSEC guys are going to mess with it just because it's used for transporting RADIUS packets?
Back to EAP-(T)TLS:
The connection between a connecting device such as a laptop, which connects to a NAS, can be secured via EAP-(T)TLS, which is a protocol transported via RADIUS packets.
This of course is supported by FreeRADIUS since ages.
OK, my understanding of EAP-TTLS/EAP-TLS is that the authentication happens in two distinct stages: the first stage (EAP-TTLS) is the outer authentication where the server presents its credentials/certificate to the client and then the secure channel is established. Phase two (EAP-TLS in my case) is where the client - via its client certificate - is actually authenticated to the RADIUS server. Now, I was hoping that the AP does this in a similar sort of way when authenticating itself to the RADIUS server, but it seems that is not the case and this is indeed a weak point.
No the NAS (It can be a WAP, VPN concentrator, Switch, Router, Terminal Server) - Does not use EAP-TTLS or any EAP based authentication method to communicate with the RADIUS server directly. As previously mentioned RADSEC does what you're asking. There's also plans for a DTLS transport layer (http://tools.ietf.org/html/draft-dekok-radext-dtls-03). But neither have been implemented by NAS vendors yet. If you want to have a secure channel of communication between the RADIUS server run the UDP packets through a VPN, or implemented a local proxy on the NAS to translate between UDP and RADSEC. Additionally, if you're using EAP-TTLS-TLS, why do you need the RADIUS communications to be secure? The sensitive data is already encrypted. In fact why are you using EAP-TTLS-TLS unless you're transporting something extra in the TTLS tunnel? Seems sort of pointless to me...
My question still remains though - since this is a two-phase authentication, two distinct sets of (ca, server, client) certificates can be used. How do I specify these in RADIUS?
raddb/modules/eap.conf - You can specify the signing CA for peer certificates for EAP-TLS. You can use two instances of the module, one for outer and one for inner if it helps you understand the concept any better.
I found that I could specify the ca, client and server certificates once (normally stored in raddb/certs if memory serves), but I potentially need two of each for each phase. I know I could use just one, but just for the sake of understanding the whole process and getting to know how it all works I need to know this. How do I do that?
See above...
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Why don't you try reading about EAP and 802.1X too?
I did.
Interesting, noted. It would be nice if this works in a similar way as the SSL handshake works - this is very secure, tested and already established in the real world.
Of course it does, it's using TLS... Thank you.
You think the RADSEC guys are going to mess with it just because it's used for transporting RADIUS packets?
Where did I said or implied that? Touche!
OK, my understanding of EAP-TTLS/EAP-TLS is that the authentication happens in two distinct stages: the first stage (EAP-TTLS) is the outer authentication where the server presents its credentials/certificate to the client and then the secure channel is established. Phase two (EAP-TLS in my case) is where the client - via its client certificate - is actually authenticated to the RADIUS server. Now, I was hoping that the AP does this in a similar sort of way when authenticating itself to the RADIUS server, but it seems that is not the case and this is indeed a weak point.
No the NAS (It can be a WAP, VPN concentrator, Switch, Router, Terminal Server) - Does not use EAP-TTLS or any EAP based authentication method to communicate with the RADIUS server directly.
As previously mentioned RADSEC does what you're asking. There's also plans for a DTLS transport layer (http://tools.ietf.org/html/draft-dekok-radext-dtls-03).
But neither have been implemented by NAS vendors yet. If you want to have a secure channel of communication between the RADIUS server run the UDP packets through a VPN, or implemented a local proxy on the NAS to translate between UDP and RADSEC.
Tunnelling is something I might consider as an alternative, thanks again for the explanation.
Additionally, if you're using EAP-TTLS-TLS, why do you need the RADIUS communications to be secure? The sensitive data is already encrypted. In fact why are you using EAP-TTLS-TLS unless you're transporting something extra in the TTLS tunnel? Seems sort of pointless to me...
Well, my understanding is that the communication between AP and RADIUS is not encrypted, isn't that so?
My question still remains though - since this is a two-phase authentication, two distinct sets of (ca, server, client) certificates can be used. How do I specify these in RADIUS?
raddb/modules/eap.conf - You can specify the signing CA for peer certificates for EAP-TLS.
You can use two instances of the module, one for outer and one for inner if it helps you understand the concept any better.
Yep, that seems like a good plan - Phil Mayers was kind enough to explain it to me. I'll probably do a bit of digging before delving in with RADIUS myself.
On 11/26/2011 04:32 PM, Andreas Rudat wrote:
so it is, you can only protect your AP client with the shared secret key.
Not necessarily. If the switch to which the WAP is connected supports 802.1x, it could act as a NAS and authenticate the WAP with EAP/TLS. -- ======================================================================== Ian Pilcher arequipeno@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ========================================================================
so it is, you can only protect your AP client with the shared secret key.
Not necessarily. If the switch to which the WAP is connected supports 802.1x, it could act as a NAS and authenticate the WAP with EAP/TLS.
By WAP I take it you mean the wireless client, right? If so, this is indeed the case - the client will be a Linux-based device with wpa_supplicant and a driver which supports nl80211/cfg80211, so I can configure - at least on the client's part - EAP-TTLS/EAP-TLS authentication. My aim is to do the same on AP and RADIUS, which is the point of actually starting this thread as my "experience" with RADIUS is nil.
On 11/26/2011 11:49 PM, Mr Dash Four wrote:
so it is, you can only protect your AP client with the shared secret key.
Not necessarily. If the switch to which the WAP is connected supports 802.1x, it could act as a NAS and authenticate the WAP with EAP/TLS.
By WAP I take it you mean the wireless client, right? If so, this is
No. WAP == Wireless Access Point.
indeed the case - the client will be a Linux-based device with wpa_supplicant and a driver which supports nl80211/cfg80211, so I can configure - at least on the client's part - EAP-TTLS/EAP-TLS authentication. My aim is to do the same on AP and RADIUS, which is the point of actually starting this thread as my "experience" with RADIUS is nil.
So you keep saying. I note however that it doesn't stop you from making judgements on its security, and you're getting a lot of stick for that (from me and others). Seriously - it's good you want to learn. But why not do that first, then ask questions based on the knowledge you've acquired and, hopefully, understood? If you're missing basic terms like "WAP" i.e. a Wireless Access Point, then I've got to say, you've got some work to do on the fundamentals... In brief, Ian was suggesting it's possible for the wireless AP to act as an 802.1x client to the upstream ethernet switch (if that's the topology). This is correct, but not IMO relevant to your concerns (however misguided) or questions.
> No. WAP == Wireless Access Point. Noted, thanks. >> indeed the case - the client will be a Linux-based device with >> wpa_supplicant and a driver which supports nl80211/cfg80211, so I can >> configure - at least on the client's part - EAP-TTLS/EAP-TLS >> authentication. My aim is to do the same on AP and RADIUS, which is the >> point of actually starting this thread as my "experience" with RADIUS is >> nil. > > So you keep saying. I note however that it doesn't stop you from > making judgements on its security, and you're getting a lot of stick > for that (from me and others). Again, I don't make "judgements", it was merely an observation. > Seriously - it's good you want to learn. But why not do that first, > then ask questions based on the knowledge you've acquired and, > hopefully, understood? If you're missing basic terms like "WAP" i.e. a > Wireless Access Point, then I've got to say, you've got some work to > do on the fundamentals... I would have done this ages ago if I knew where to find a more comprehensive manual explaining it all, rather than relying on bits of info scattered in thousand different places. The freeRADIUS wiki isn't terribly helpful either - this -> http://wiki.freeradius.org/create/Extensible-Authentication-Protocol#EAP-TTLS - being the perfect example - in order to access it I have to log in because "authentication is required" (as if!).
I would have done this ages ago if I knew where to find a more comprehensive manual explaining it all, rather than relying on bits of info scattered in thousand different places. The freeRADIUS wiki isn't terribly helpful either - this -> http://wiki.freeradius.org/create/Extensible-Authentication-Protocol#EAP-TTL... - being the perfect example - in order to access it I have to log in because "authentication is required" (as if!).
That's BS. How do I know that's BS? BECAUSE I WROTE THE DAMN AUTHENTICATION GLUE! The wiki does NOT require you to login to view content, that's the whole point of the new wiki. You're trying to access a page that doesn't exist. If you had even bothered to read the URL you'd have seen that it contained the word create, that would have given you a clue. Try http://wiki.freeradius.org/EAP#EAP-TTLS and it'll work fine. Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
The wiki does NOT require you to login to view content, that's the whole point of the new wiki. You're trying to access a page that doesn't exist. If you had even bothered to read the URL you'd have seen that it contained the word create, that would have given you a clue.
Not trying to excuse mister clueless, but it could maybe be made more obvious that the link does not yet exist and the the login appears as an offer if you want to create it? I could easily miss the fact that the URL changes when accessing e.g. http://wiki.freeradius.org/Foo And I guess that if you've never seen a RADIUS packet, then you might not have seen a Wiki before either :-) Bjørn
participants (10)
-
Alan Buxey -
Alan DeKok -
Andreas Rudat -
Arran Cudbard-Bell -
Bjørn Mork -
Ian Pilcher -
Mr Dash Four -
Phil Mayers -
Stefan Winter -
Sven Hartge