Reivindicações de segurança

Nos termos definidos na RFC 3748, as reivindicações de segurança para EAP-TTLSv0 são as seguintes:

• Authentication mechanism: TLS plus arbitrary additional protected authentication(s)
• Ciphersuite negotiation: Yes
• Mutual authentication: Yes, in recommended implementation
• Integrity protection: Yes
• Replay protection: Yes
• Confidentiality: Yes
• Key derivation: Yes
• Key strength: Up to 384 bits
• Dictionary attack prot.: Yes
• Fast reconnect: Yes
• Cryptographic binding: No
• Session independence: Yes
• Fragmentation: Yes
• Channel binding: No

Mecanismo de autenticação

EAP-TTLSv0 utiliza protocolos de autenticação e negociação tanto na fase 1 com o handshake TLS quanto na fase 2 no tunelamento da autenticação. Em uma implementação típica no mínimo o servidor é autenticado para o cliente na fase 1, e o cliente autentica o servidor AAA/H na fase 2. Na fase 1, a autenticação do servidor para o cliente é tipicamente por certificado, o servidor opcionalmente também pode autenticar o cliente baseado em certificado. A fase 2, autenticação do servidor AAA/H é tipicamente por senha ou símbolo (token) através de um mecanismo EAP de autenticação ou outro qualquer que opere essa função. Essa autenticação pode ser em uma via ou mútua.

Ciphersuite negotiation

SIM - A negociação de uma suíte de Cifras é herdada de TLS.

Mutual authentication

SIM - A recomendação mínima é que o servidor TTLS seja autenticado na fase 1, e o cliente e o servidor AAA/H sejam mutuamente autenticados na fase 2.

Integrity protection

SIM - A proteção da integridade é herdada de TLS.

Replay protection

SIM - Herdada de TLS

Confidentiality

SIM - Herdade de TLS. Observe que EAP-TTLSv0 não fornece encriptação para pacotes EAP de sucesso ou falha.

Key derivation

Os valores para MSK e EMSK são derivados. A derivação de chaves é herdada de TLS, e a agilidade desse mecanismo depende diretamente da agilidade da função PRF TLS.

Key strength

A força da chave é limitada ao tamanho da chave mestra de TLS, que nas versões 1.0/1.1 correspondente a 384 bits ou 48 octetos.

Dictionary attack protection

A fase 2 da autenticação da senha está protegida contra escutas e conseqüentemente contra ataques de dicionário (offline) contra a criptografia TLS.

Fast reconnect

É garantido pelo reinício da sessão TLS.

Cryptographic binding

***************************************************************
NT: Essa é uma característica de segurança onde EAP-TTLS falha. Para entender melhor esse requerimento estou adicionando o trecho referente a RFC 3748 onde esse parâmetro é definido.
***************************************************************

***************************************************************
Cryptographic binding - A demonstração de um par EAP para um servidor EAP de que uma única entidade está agindo como par para todos os métodos executados em um método que use um túnel criptográfico. Essa demonstração também pode ser requerida em sentido contrário. Caso seja corretamente implantada em um servidor essa característica pode atenuar os ataques do tipo Homem no Meio (man-in-the-middle). Fonte: "RFC 3748"
***************************************************************

[MITM] descreve uma vulnerabilidade característica dos protocolos de autenticação tunelados, na qual um atacante se autentica como um cliente através do protocolo tunelado, e se coloca como um autenticador para um cliente legítimo usando um protocolo não tunelado. Quando esse cliente legítimo apresenta suas credenciais, e a mesma pode ser usada em ambos métodos de autenticação o invasor atua como um falso autenticador. EAP-TTLSv0 é vulnerável a esse tipo de ataque. Deve ser evitado o uso conjunto de protocolos tunelados e não tunelados no mesmo servidor.

Uma versão futura ou mesmo uma extensão de TTLSv0 pode definir a utilização de material criptográfico gerado pelos métodos de autenticação interna em conjunto com o material gerado pelo handshake TLS.

Session independence

TLS garante a independência da sessão com sua chave mestre, da qual são derivadas por EAP-TTLSv0 o MSK e o EMSK.

Fragmentation

A fragmentação de pacotes EAP é prevista.

Channel Binding

***************************************************************
NT: Essa é outra característica de segurança onde EAP-TTLS falha. Para entender melhor esse requerimento estou adicionando o trecho referente a RFC 3748 onde esse parâmetro é definido.

Channel Binding - Significa que a comunicação através de um método EAP que implementa segurança ponto-a-ponto através de um canal, pode ser comparada a segurança implementada a métodos fora da banda, como protocolos AAA ou segurança da camada baixa. ***************************************************************

O suporte a Channel Binding poderá ser adicionado com uma extensão em versões futuras, usando as AVPs apropriadas.

Anonimato do cliente

Ao contrário de outros métodos EAP, o método EAP-TTLS não envia o nome do usuário (username) no formato de texto puro no início da troca de pacotes em uma sessão EAP-Response/Identity. Essa característica é fundamental para suportar o anonimato e a privacidade de localização em relação aos atacantes com escutas na rede entre o cliente e o servidor TTLS.

Todavia, implementadores devem estar cientes que outros fatores, tanto no âmbito de EAP-TTLS ou em outros partes, e que possam comprometer a identidade do usuário. Por exemplo, se um usuário se autentica usando um certificado durante a fase 1 de EAP-TTLS, um nome gravado no certificado pode revelar a identidade desse usuário. Fora do âmbito de EAP-TTLS um endereço MAC ou nos casos das conexões wireless, uma assinatura rádio, também podem revelar informações que levam ao usuário.

Os implementadores ainda devem estar cientes que a identidade do usuário não é oculta para o servidor EAP-TTLS e pode ser incluída na forma de texto puro em mensagens AAA entre o ponto de acesso, o servidor EAP-TTLS e o servidor AAA/H.

A RFC 5216 descreve uma técnica na sessão "privacidade" usada para proteger a privacidade de clientes que utilizam um certificado. O cliente envia uma lista de certificados vazia, de modo que o servidor emita um ServerHello completando o handshake da fase TLS, e iniciando a segunda fase, com um handshake encriptado, onde o cliente realmente envia sua lista de certificados. Para que essa técnica funcione é precisa que ambos os lados tenham suporte a essa função. O cliente deve saber isso de antemão.

A confiança no servidor

A confiança em um servidor é assumida quando um cliente recebe um certificado durante a fase de handshake TLS. O cliente deve ter um meio de saber quais servidores TTLS são confiáveis e quais não são. A conseqüência de prosseguir a autenticação com um servidor hostil é expor a autenticação interna a um ataque.

Validação do certificado

Quando qualquer uma das partes apresenta um certificado como parte de um handshake TLS, toda a cadeia de validação (menos a raiz – root) deveria ser enviada como forma de facilitar a autenticação pela outra parte.

E quando uma parte recebe um certificado, ela deve validar todo o caminho do certificado até a raiz confiável (root). Caso o emissão não envie certificados intermediários, o recebedor pode usar certificados em cache ou cópias pré-configuradas, se disponíveis, ou ainda recuperar esses certificados pela Internet, se possível.

Clientes e servidores devem implementar políticas relacionadas para EKU - Extended Key Usage - RFC 3280 - em relação aos certificados recebidos, para garantir que o certificado está em uso para o qual se destina. Tipicamente, um cliente EKU, quando presente, seria esperado receber um valor para id-kp-clientAuth. Um servidor, esperaria id-kp-serverAuth. Observe que ausência de uma extensão EKU ou um valor para anyExtendedKeyUsage implica na ausência de restrição na finalidade de propósito para o certificado.

Comprometimento do certificado

A revogação de um certificado deve ser checada para evitar que um impostor utilize um certificado comprometido. Chegar o certificado de um servidor contra uma lista de revogações não é sempre possível para um cliente, ele não tem acesso a rede até completar sua autenticação.

Esse problema pode ser atenuado com o uso de OCSP [RFC 2560] durante o handshake TLS, como descrito em RFC 4366.

Rotatividade do segredo

Com o uso alternado de segredos, a revelação de um segredo não compromete as chaves de uma sessão previamente negociadas baseada nesse segredo que vazou. Então, a rotação de chaves é feita pelo algoritmo TLS, caso a chave privada do certificado do servidor é roubada ou quebrada, a senha de um usuário que tenha sido tunelada permanecerá em segurança, desde que esse certificado não seja mais usado. O algoritmo Diffie-Hellman é um exemplo de algoritmo que fornece a rotatividade de segredos.

O uso da rotatividade de segredos deve ser considerada caso o ataque a gravação da autenticação ou dados da sessão são considerados uma ameaça real e significativa.

Ataques de negociação de versão

EAP-TTLS negocia automaticamente a versão do protocolo, antes que a segurança seja estabelecida pelo túnel TLS. Em princípio é possível a existência de um ataque onde ocorra a modificação da mensagem em trânsito para que ocorra uma negociação para uma certa versão de determinando protocolo de segurança. Cada uma das partes apresenta a maior versão com a qual é possível trabalhar.

A versão atual de EAP-TTLS é a versão zero, então esse tipo de ataque não é previsto. Todavia, a próxima versão desse protocolo deverá incluir um mecanismo de proteção contra esse tipo de ataque. Uma proposta seria enviar uma AVP após a criação do túnel, reiterando a versão em uso.