First of all, thanks for this!! A couple of different emergencies have stolen my time for implementing this, which is why I have not replied.
I will hopefully get to try this soon. Meanwhile, now there is talk about using DUO! If that gets approved, we may pivot to that, at least for CHAP users, since my guess would be that DUO supports CHAP natively since there's no need to embed a PIN. -----Original Message----- From: radiator <radiator-boun...@lists.open.com.au> On Behalf Of Heikki Vatiainen Sent: Monday, March 14, 2022 10:03 AM To: radiator@lists.open.com.au Subject: Re: [RADIATOR] CHAP and Google Authenticator On 8.3.2022 18.58, d...@carrierip.net wrote: > But now we want to add MS-CHAP v2 support, since apparently some Android > devices won't work without it. But CHAP doesn't transmit via clear text > the way PAP does. The only way I can imagine this working is to totally > redo the plumbing to something like this: The current release, Radiator 4.26, supports different CHAP versions if configured to do so. > 1. User still enters "password:code" Ok, or rather use "passwordcode" because there's no way to extract the parts on the Radiator side. > 2. CHAP at the client uses the NAS-supplied challenge to hash that to > "abcdefghijklmnopqrstuvwxyz" and sends it to Radiator Lets continue from the point when Radiator receives a CHAP, MSCHAP or MSCHAPv2 request. The CHAP type can be determined by which attributes are in the requests. > 3. Radiator doesn't try to parse this anymore > 4. Radiator fetches the user's password from the database and > determines the current TOTP for that user and builds its own > "server_password:server_code" string One piece of information Radiator fetches for TOTP is PIN. This PIN can be combined with expected TOTP and the value is then hashed according to the chosen CHAP type. It's not possible to get the password/PIN from another DB at this time. > 5. Radiator uses the previously-shared challenge to hash that string to > "server_abcdefghijklmnopqrstuvwxyz" > 6. If "abcdefghijklmnopqrstuvwxyz" = > "server_abcdefghijklmnopqrstuvwxyz", then Accept; else, Reject The above would work when the PIN is used as the password in "passwordcode". You'd need a configuration like this: <AuthBy SQLTOTP> DBSource dbi:... DBUsername ... DBAuth ... AuthenProto PAP, MSCHAPv2 </AuthBy> The default SQL query already fetches the PIN for the user but you need to enable MSCHAPv2 explictly. > So my questions are: > > 1. Am I getting this right? How NAS and the end user bootstrap the authentication may vary, but otherwise it goes like that. > 2. How have other people solved this problem? > 3. Any tips on the best way to implement this in Radiator? If it's possible to use the PIN field in the TOTP DB, then 4.26 and later should already work. > 4. Do I need to also be concerned that the Google Auth Secrets of users > are also only available to Radiator as hashes? I'd say a plain text TOTP value and a hashed TOTP value do not differ that much because their usefulness is limited by the validity time window. Radiator checks for replay when a CHAP method is used, so in that sense they work similarly too. Thanks, Heikki -- Heikki Vatiainen OSC, makers of Radiator Visit radiatorsoftware.com for Radiator AAA server software _______________________________________________ radiator mailing list radiator@lists.open.com.au https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open .com.au%2Fmailman%2Flistinfo%2Fradiator&data=04%7C01%7Cdave%40corp.netca rrier.com%7Cd47823add98f4f62856d08da05c3a90e%7C0cb89eef04a7465c893f447a3df63 d9b%7C0%7C0%7C637828635154139665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j%2F1PcmxkV OuS6tRi4PwBVPkkfoNpiSSrAFxbR98TPsA%3D&reserved=0 _______________________________________________ radiator mailing list radiator@lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator