hWhen using remote authentication on switches, most will primarly support PAP, the simplest method. This way the password is sent MD5 encrypted (to my knowledge) via the shared secret between the NAS and the RADIUS server. Nowadays this isn't considered to be secure, nonetheless I don't expect most devices to support RADSEC when the don't do it already to today. Anyhow, one misconfiguration I ran into was that I saw my own password leaked in plaintext to logfiles only when loggin into a switch, not using PEAP-MSCHAPv2 via WLAN
The log lines of a successful PEAP-MSCHAPv2 login (Wireless LAN) don't leak problematic information:
Sun Oct 13 10:22:07 2013 : Auth: Login OK: [username/<via Auth-Type = EAP>] (from client wifi-aps 0 via TLS tunnel) Sun Oct 13 10:22:08 2013 : Auth: Login OK: [username/<via Auth-Type = EAP>] (from client wifi-aps 0 cli <MAC-address>)
The second line is due to "use_tunneled_reply = yes" which is helpful for accounting since otherwise the outer tunnel doesn't get much useful data when users use an anonymous outer identity. However when authentication requests get logged from a PAP authentication, things look quite bad:
Sun Oct 13 11:21:41 2013 : Auth: Login OK: [myadmin/myPasswordInPlaintext] (from client switches port 0)
The cause was that I enabled logging authentication requests, where default is set to no (likely for performance reasons):
/etc/freeradius/radiusd.conf:
log { ... # Log authentication requests to the log file. # # allowed values: {no, yes} # auth = yes }
The solution I found via the FreeRADIUS list archives was actually simple, the default (on Debian) is to log good and bad passwords - but that's only happening if you log authentication requests. Thus: when logging auth requests and with PAP - don't forget to disable good and bad passwords logging!
log { ... # Log passwords with the authentication requests. # auth_badpass - logs password if it's rejected # auth_goodpass - logs password if it's correct # # allowed values: {no, yes} # auth_badpass = no auth_goodpass = no ... }