On 2012-12-13, Aleš Golob <[email protected]> wrote: > Hi! > > I have an OpenBSD 5.2 installation on a Soekris net4801 used as > a router, DNS server and a SSH tunnel proxy. > > I have configured the login_radius service in my login.conf and > all works reasonably well but from what I can tell login_radius > only supports the clear-text PAP authentication type.
Normally PAP is used as part of PPP and then the PPP server can use RADIUS to check this password. In this case the cleartext part is where the password is sent from the PPP client to server. If RADIUS is then used to authenticate that password, it does *not* use a clear-text password protocol, the protocol is explained here: http://tools.ietf.org/html/rfc2865#page-27 Note: while not clear-text, PAP is not a modern high-security protocol. You probably want to protect it at a lower layer, either with IPsec or similar, or via physically secured networks. Note 2: while not clear-text, CHAP is not a modern high-security protocol. You probably want to protect it at a lower layer, either with IPsec or similar, or via physically secured networks. Additionally CHAP requires that the authentication server have access to a plaintext copy of the user's password. If the auth server is successfully attacked *all* user passwords can be obtained. > So my question is am I missing something and it's possible to use > CHAP or any other encrypted auth types with login_radius You're not missing anything, login_radius doesn't support CHAP. > I would normaly not make a fuss about it but OpenBSD being as > security centric as it is I find it a bit awkward it would support > only a plain-text method in such an important auth mechanism. IMHO adding CHAP support to login_radius would be useless. The case it is trying to protect is where the user's password is sent over a clear channel as with PPP/PPPoE/L2TP; login_radius isn't used for these. EAP might be of more interest but only a couple of mechanisms are valid for what login_radius does; EAP-TTLS + password authentication (which can functionally be replaced with IPsec + password auth), or possibly EAP-PSK using the password as the key (in which case, as with CHAP, the auth server would require unencrypted access to the key).
