[RADIATOR] CHAP and Google Authenticator

[dave at carrierip.net]

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-bounces at lists.open.com.au> On Behalf Of Heikki
Vatiainen
Sent: Monday, March 14, 2022 10:03 AM
To: radiator at lists.open.com.au
Subject: Re: [RADIATOR] CHAP and Google Authenticator

On 8.3.2022 18.58, dave at 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 at 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