[RADIATOR] CHAP and Google Authenticator

[Heikki Vatiainen]

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