Comments on Active Directory IdP and YubiKey OTP integration that supports MS-CHAP v2

[Alan DeKok]

On Feb 22, 2021, at 4:45 PM, David Herselman via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> I was hoping the following may provide a more complete start to finish integration guide for others that may have similar requirements. I would very much like to invite dialogue regarding any recommendations anyone may have.

  Long detailed instructions are good.  If possible, updating the Wiki might help.

> Our requirements were:
> 
>  *   RADIUS servers domain joined to handle PAP and MS-CHAP v2 authentication using information only from Active Directory
>  *   We do not want to store credentials in AD with reversible encryption

  "passwords" maybe?

>  *   AD Group membership validation based on source
>  *   Yubico OTP Multi-Factor Authentication (MFA)
> 
> System are domain joined as member servers using Samba. Samba winbind subsequently presents users and groups as native system accounts, which allows references to just the group name and unlike LDAP does not make the link sensitive to the placement of the security group within the AD folders or organisational units (distinguished name or DN). Password Authentication Protocol (PAP) transmits unencrypted passwords (i.e. plain-text) over the network

  To be clear: passwords are encrypted using some crappy RADIUS-specific scheme.  It's been done since 1993, and no one has been able to break it using methods other than brute force.

> so connectivity should be encrypted using either IPSec or TLS (RadSec or EAP-TTLS).

  That's still a good recommendation.  TLS and IPSec are *much* better than whatever weird RADIUS encryption is being used for the password.

> MS-CHAP v2 provides mutual authentication and uses a hash of the password.

  Anyone who can monitor the MS-CHAP data can pretty trivially break it.  So MS-CHAP should *also* be secured using IPSec or TLS.

> This means that the request only includes a hash representing the password, so there is nothing to cut the password and OTP out of. One can however transmit the OTP as the username and then lookup the associated owner's AD account name for FreeRADIUS to retrieve the hash used during authentication via Samba winbind.
> 
> Yubico devices generate a unique 32 character modhex passcode each time you press the button on a YubiKey 5 or scan it using NFC. This passcode comes after a 12 character public id, which is unique to each YubiKey. We therefore have two method of transmitting the OTP during login. The first is the classic RSA token method (although reversed) where we use our username, type our password and then press the YubiKey button, herewith an example:
>  Username: davidh
>  Password: secretcccccct00001krbhnvrjrdlujuujdcjvltdcrdkhhtit
> 
> This method requires PAP, as we require the client to transmit the entered credentials, so that we can cut the information in to a password and Yubico OTP.
> 
> The alternative is to make use of the YubiKey's public ID to lookup the AD username. This method works for PAP and allows MS-CHAP v2 authentication, herewith an example:
>  Username: cccccct00001krbhnvrjrdlujuujdcjvltdcrdkhhtit
>  Password: secret
> 
> In the second case we type out password out and then press the YubiKey when prompted for the username. Devices we were authenticating to are generally switches and routers where we can transmit attributes as part of the access accept message to grant eg access permissions. Some platforms however (eg Check Point Management and VyOS) require user accounts to be defined, in those cases you are stuck with PAP being the only possible integration.

  Ugh.  They should just use RADIUS.  That's what it's designed for.

  This solution is a little weird.  But if it works, ship it!

  And yes, there's nothing really wrong here.  You're playing games with names / passwords.  You're *not* making anything insecure.

  Alan DeKok.