Gostaria de configurar um gateway VPN IKEv2 para que vários usuários remotos acessem uma rede privada.
Eu tenho uma configuração de teste onde o respondente se autentica com um certificado autoassinado. O iniciador autentica com um nome de usuário e senha.
Alguns problemas:
- O certificado é muito complicado. Não configurarei uma PKI adequada, portanto, um certificado autoassinado que deve ser distribuído a cada cliente e configurado para ser confiável equivale a uma chave pré-compartilhada (PSK), embora seja substancialmente mais difícil de gerar e administrar.
- O iniciador é autenticadoapenaspor um nome de usuário e senha, e assim um invasor externo pode facilmente tentar adivinhar senhas fracas ou comprometidas.
Além de implantar uma PKI adequada, prefiro executarmútuoautenticação dos hosts iniciador e respondedor por meio de um PSK. Essa chave seria distribuída com segurança a todos os usuários. Atacantes externos não teriam o PSK e, portanto, uma senha fraca ou comprometida seria insuficiente para acesso. A autenticação de nome de usuário e senha permite a identificação e autorização de um usuário específico em um sistema de diretório existente, sem a necessidade de gerar e distribuir chaves exclusivas para cada usuário.
Isso é possível com o IKEv2? Pelo que sei, isso foi possível através do Xauth no IKEv1. Mas para IKEv2 não tenho tanta certeza: em uma leitura superficial deRFC 5996, seção 2.16, parece que este pode não ser o caso. A autenticação de nome de usuário e senha aconteceria através de algum método EAP e:
Um iniciador indica o desejo de usar EAP omitindo a carga útil AUTH da primeira mensagem na troca IKE_AUTH. (Observe que a carga útil AUTH é necessária para autenticação não EAP e, portanto, não está marcada como opcional no restante deste documento.)
Isso parece sugerir que o iniciador pode usar apenas EAP (nome de usuário e senha) ou PSK.
Embora a questão seja sobre o protocolo IKEv2, pretendo implementar o final do respondedor com o Strongswan, portanto, qualquer conhecimento adicional será apreciado.
Responder1
A autenticação de cliente e servidor em IKEV2 não está relacionada. Então, em teoria, você pode autenticar o servidor com PSK e o cliente com EAP. No entanto, oRFC afirma o seguinteem relação à autenticação EAP:
Além da autenticação usando assinaturas de chave pública e segredos compartilhados, o IKE suporta autenticação usando métodos definidos na RFC 3748 [EAP]. Normalmente, esses métodos são assimétricos (projetados para um usuário autenticado em um servidor) e podem não ser mútuos. Por esse motivo, esses protocolos são normalmente usados para autenticar o iniciador para o respondedor.e DEVE ser usado em conjunto com uma autenticação baseada em assinatura de chave pública do respondente para o iniciador.
Portanto, combinar a autenticação do servidor PSK com a autenticação do cliente EAP não é compatível com o RFC. Porém, é possível configurá-lo com o strongSwan. Mas observe que a maioria dos clientes não permite essa combinação.
Na verdade, muitos clientes roadwarrior não oferecem suporte à autenticação PSK, pois é um risco potencial à segurança em tais cenários se o mesmo PSK for usado com vários clientes, porque todos os clientes que conhecem o PSK são, em teoria, capazes de personificar o servidor.
Eu tenho uma configuração de teste onde o respondente se autentica com um certificado autoassinado.
Por que não usarVamos criptografar?
O iniciador é autenticado apenas por nome de usuário e senha e, portanto, um invasor externo pode facilmente tentar adivinhar senhas fracas ou comprometidas.
Usar um PSK para autenticar o servidor não mudará isso. Você precisaria adicionar um segundo fator à autenticação do cliente para fazer algo a respeito (ou seja, usar primeiro um certificado ou PSK e depois fazer o EAP). No entanto, isso requer apoio paraRFC 4739, que falta a muitos clientes (no entanto, o StrongSwan oferece suporte).