freeradius dois fatores sem concatenação de fator

3

Eu tenho um roteador cisco fornecendo um servidor SSL VPN que está falando com o freeradius, que por sua vez usa o pam e dois módulos pam (sss & yubico) para fornecer autenticação de dois fatores para a VPN.

Tudo é bom no mundo e funciona, exceto que para isso funcionar eu preciso concatenar a senha do usuário e o token yubikey juntos em uma resposta. Meus usuários prefeririam uma senha de dois estágios e uma resposta de desafio (principalmente por motivos de "muito confuso"). Isso pode ser feito?

No momento eu tenho uma seção de configuração de autenticação radius que especifica usar o módulo pam radius como backend. Eu sou muito novo no radius mas acho que poderia usar o módulo pam duas vezes em duas "fases" separadas e fornecer um pam_auth diferente a cada vez, para que dois arquivos de configuração pam diferentes sejam usados, com cada apoiado em um único módulo pam (IPA em um, yubikey no outro)? Eu estaria confiando em pam duas vezes porque o freeradius não suporta yubikey nem sss fora da caixa (eu sei que ele suporta ldap mas eu quero sss para ganhar dns failover de registro SRV etc).

Não tenho certeza se isso é possível, e não tive sorte em encontrar algum lugar documentado?

O freeradius obviamente tem muitos arquivos de configuração, mas se é crucial saber que posso postá-los.

    
por Sirex 28.04.2014 / 04:12

2 respostas

1

Depois de ter tentado obter uma configuração do yubikey para fazer isso por algum tempo (embora não com o OpenVPN) cheguei à conclusão de que, se isso é para funcionar, tem que ser suportado ambos pelo aplicação e pelo PAM. Ou seja, o aplicativo tem que saber para pedir três coisas (em vez das duas usuais) e a biblioteca PAM subjacente deve saber esperar que três coisas sejam passadas para ela (e usá-las apropriadamente) ).

A biblioteca PAM do yubikey não parece ter esse suporte, ou pelo menos não o teve de forma confiável enquanto eu ainda tentava fazer isso funcionar.

Em vez disso, decidi mudar para usar o meu yubikey no modo OATH, e descobri que a autenticação em três fases apropriada era muito mais bem tratada tanto pelo sshd quanto pela biblioteca pam_oath subjacente.

Eu não posso dizer se o OpenVPN suporta isso melhor, já que eu não tentei, mas você pode querer investigar isso como uma opção se você não conseguir o modo yubikey funcionando corretamente. Tem a vantagem adicional de que, se algum dos seus usuários não pode usar um yubikey por algum motivo (por exemplo, OpenVPN de um endpoint sem porta USB), há uma série de outras implementações OATH que podem ser usadas, e. em um smartphone para libertar esses usuários específicos sem ter que reformular completamente sua infra-estrutura de dois fatores.

Caso seja de seu interesse, meu writeup em autenticação sshd / yubikey / OATH / two-factor / three-phase pode ser encontrado aqui .

Editar : não, por aplicativo eu quis dizer OpenVPN. O OpenVPN deve saber pedir (efetivamente) duas senhas separadas e um nome de usuário, e o módulo PAM de apoio deve saber esperar esses três tokens e combiná-los de uma maneira que seja agradável ao FreeRADIUS. É quase irrelevante o que é esse método acordado, desde que os tokens sejam validados; O importante é que o lado voltado para o cliente de todo o mecanismo de autenticação saiba como solicitar e como lidar com os três diferentes tokens.

Tentar criar o seu próprio, subestimulando o PAM a chamar o plug-in RADIUS duas vezes, com argumentos diferentes a cada vez, e esperando que de alguma forma apareça magicamente, parece fadado ao fracasso para mim (além de repleto de potencial buracos de segurança).

Meu ponto de maior importância é que você estava mais propenso a encontrar uma solução projetada usando o OATH do que os manipuladores de token específicos do yubikey, já que eu sabia pelo que eu tentei que os manipuladores específicos do yubikey não pareciam gostar abordagens de três token, preferindo a abordagem catenate-password-and-OTP (que eu também não gosto).

    
por 28.04.2014 / 07:54
1

O RADIUS oferece resposta ao desafio . Ou seja, você poderia primeiro fornecer a senha para o servidor radius, o servidor RADIUS verificaria a senha e se a senha não respondesse com um Access-Accept, mas com um Access-Challenge. O cliente Radius (pam_module) solicitaria a segunda autenticação e o valor OTP poderia ser enviado ao servidor RADIUS. Se a segunda parte (valor OTP) estava certa, o servidor RADIUS finalmente responderia com ACCESS-Accept.

privacyIDEA oferece respostas a desafios para vários tokens OTP (HOTP, Yubikey) e um módulo FreeRADIUS que suporta respostas a desafios.

Olhando para o código freeradius , parece que o pam_radius_auth também suporta desafio resposta, mas eu não testei ainda.

    
por 10.07.2014 / 21:35