hi all, rather than a problem, this is a question. I assume you know what eduroam is, but just in case: What is eduroam eduroam which stands for Education Roaming, is a RADIUS-based infrastructure that uses 802.1X security technology to allow for inter-institutional roaming. Substitute institutional with 'university' and you get the picture. So basically this is a hierarchy of radius servers at european level. Implementing it from my side (that of a university) has been rather trivial. What happens is that the EAP conversation traverls in cleartext across the public internet (really the inter-university networks). I would assume that EAP-TLS is highly safe from this point of view, am I right? Bye Inverse -- "In a sea of glass shards, I hear you screaming" --icchan
inverse wrote:
Implementing it from my side (that of a university) has been rather trivial. What happens is that the EAP conversation traverls in cleartext across the public internet (really the inter-university networks). I would assume that EAP-TLS is highly safe from this point of view, am I right?
Yes. Alan DeKok.
Hi,
rather than a problem, this is a question. I assume you know what eduroam is, but just in case: What is eduroam
several members of this list are involved in eduroam at sites worldwide.
What happens is that the EAP conversation traverls in cleartext across the public internet (really the inter-university networks).
cleartext? not really. the proxied traffic will be at least encapsulated via a shared secret between each RADIUS end point. and the inner method itself is sat in the EAP tunnel. unless using very old method like EAP-MD5. ideally you wouldnt use a PAP method either - MSCHAPv2 challenge response in PEAP or EAP-TTLS would give greater security. however, EAP-TLS is the defacto top-level way of doing it. platinum service, as it were - but you've got to have a full PKI infrastructure for creation, deployment and revokation. looking to the future, RADSEC will be involved in 'beefing up' the RADIUS to RADIUS communication channel. as well as the automatic assignment/discovery of AAA end point systems. alan
On Feb 18, 2008 12:32 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
cleartext? not really. the proxied traffic will be at least
This regards EAP-TLS: I meant that at least the username is shown, and you can get additional information reading the attribute values. Other than that, everything else seems useless but I just say the conversation is not completely encapsulated if that's what you mean. Anyways I'm not worried.
encapsulated via a shared secret between each RADIUS end point.
snip
would give greater security. however, EAP-TLS is the defacto top-level way of doing it. platinum service, as it were - but you've got to have a full PKI infrastructure for creation, deployment and revokation.
We have our PKI, we routinely revoke certificates and distribute the crl. This happens not without our share of anality, taken care of by scripts (written with my blood, over human skin) that restart radiusd and check that everything is still working fine, including the event of an expired/invalid crl or an out of service PKI. So, if there is any configuration option to encapsulate the full UDP payload without revealing anything, I'm more than glad to hear something about it because I must admit ignorance regarding this particular matter. If there isn't one, never mind, just means I misunderstood.
looking to the future, RADSEC will be involved in 'beefing up' the RADIUS to RADIUS communication channel. as well as the automatic assignment/discovery of AAA end point systems.
seems interesting bye! Inverse -- "In a sea of glass shards, I hear you screaming" --icchan
Hi,
unless using very old method like EAP-MD5.
which is forbidden in the eduroam policy anyway. For the exact reason of not providing sufficient security (no mutual authentication).
looking to the future, RADSEC will be involved in 'beefing up' the RADIUS to RADIUS communication channel. as well as the automatic assignment/discovery of AAA end point systems.
RadSec is RADIUS over TCP+TLS. This means that the attributes which are unencrypted in RADIUS (User-Name, Calling-Station-Id, ...) will be hidden inside a TLS tunnel and will only be visible to the RADIUS servers involved in proxying, not any IP node underway as is current with RADIUS alone. Concerning RadSec, you might like to read the current Internet-Draft: http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
inverse -
Stefan Winter