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: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
signature.asc
Description: This is a digitally signed message part.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
