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
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
