EAP-TTLS permite que a informação de autenticação do usuário seja tunelada com o uso da camada de gravação TLS, transferindo dados entre o cliente e o servidor TTLS, garantindo a segurança e autenticidade das informações protegendo contra ataques passivos e ativos entre o cliente e o servidor TTLS. Nos caso em que o encaminhamento é necessário o servidor TTLS decripta e encaminha a informação para AAA/H usando um protocolo AAA.

A qualquer tempo uma senha ou outro modo de autenticação pode ser tunelado. Também é possível que múltiplos túneis sejam usados para autenticar.

Desafio implícito

Certos protocolos de autenticação que usam o mecanismo de desafio/resposta invocam o material de desafio que não foi gerado pelo servidor de autenticação, e , por isso, requerem tratamento especial.

Nos protocolos CHAP, MS-CHAP e MS-CHAPv2, por exemplo, o ponto de acesso emite um desafio para o cliente, que combina o desafio com a senha e gera um hash que é enviado de volta ao ponto de acesso como resposta. O ponto de acesso então encaminha ambos (desafio e resposta) ao servidor AAA. Mas em função de não ter sito o servidor que gerou o desafio, isso faz com que alguns desses protocolos fiquem sujeitos aos ataques de repetição.

Caso o cliente seja capaz de criar seu próprio desafio e resposta, um atacante capaz de observar os pacotes CHAP ou MS-CHAP pode representar um risco para esse usuário, mesmo sob EAP-TTLS.

Para tornar esses protocolos seguros sobre EAP-TTLS, é necessário fornecer um mecanismo que produza um desafio e que o cliente não possa controlar ou predizer. Isso é feito usando a mesma técnica descrita anteriormente para fazer a geração de material criptográfico.

Quando um mecanismo de autenticação baseado em desafio é usado, tanto o cliente quanto o servidor usam uma função pseudo-aleatória para gerar tantos octetos quantos forem requeridos para o desafio.

Neste caso, uma cadeia de caracteres é utilizada como constante. Seu conteúdo será "ttls challenge". As outras partes envolvidas são a chave secreta master e os valores aleatórios estabelecidos durante a fase de handshake. O formato dessa função será como a seguir:


O número de octetos a serem gerados (nn) depende do método de autenticação e é indicado abaixo para cada um dos métodos que requerem geração de um desafio implícito.

Protocolos de autenticação tunelados

Essa sessão descreve os métodos específicos para tunelamento de protocolos em EAP-TTLS.

Para fins de explicação, é assumido que o servidor TTLS e AAA/H usam RADIUS, assim como o protocolo de portadora entre eles. Todavia, isso não é um requerimento, e qualquer protocolo AAA capaz de entregar as informações pode ser usado.

O cliente define qual protocolo de autenticação será usado através das AVPs envidadas inicialmente ao servidor como descrito a seguir.

Observe que certos protocolos de autenticação descritos a seguir utilizam AVPs Vendor-Specific que originalmente foram definidas por RADIUS. O modo como RADIUS e Diameter especificam os atributos de Vendor-Specific são diferentes. Enquanto RADIUS usa o formato 26 (descrito no protocolo RADIUS), Diameter usa um conjunto de V-bit para indicar a presença do atributo Vendor-ID. O formato de RADIUS é sempre conversível para Diameter. Todas as AVPs que tenham Vendor-Specific devem ser codificadas usando o mecanismo V-bit.

EAP

Quando EAP é o protocolo de autenticação tunelado, cada pacote EAP tunelado entre o cliente e o servidor TTLS é encapsulado em uma mensagem EAP AVP antes do tunelamento através da camada de gravação TLS.

Observe que AVP é um padrão de Diameter e não está limitada a 253 octetos de dados, como estão os atributos quando envidados no formato nativo de RADIUS. O modo com que RADIUS trata os atributos em mensagens EAP não é apropriado para EAP-TTLS.

O cliente inicializa EAP por meio de uma mensagem tunelada EAP-Response/Identity para o servidor TTLS. Dependendo dos requerimentos do protocolo interior, o cliente PODE agora colocar seu username neste pacote, pois a privacidade é garantida pela encriptação TLS. O username é tipicamente um nome NAI no formato username@realm.

A parte @realm é opcional, entretanto, quando há encaminhamento da solicitação para um servidor AAA/H é necessário incluir essa porção para auxiliar na resolução de nomes do domínio.

Observe que o cliente tem duas oportunidades para especificar seu realm (NT: a tradução literal é área ou reino. O sentido neste contexto é de domínio em um nome FQDN). A primeira, no início, ao enviar o pacote EAP-Response/Identity ao servidor TTLS. A segunda, ocorre como parte da troca EAP com o túnel EAP-TTLS. Assim, o ponto de acesso somente precisa saber qual a rota para o domínio do servidor TTLS correspondente. É presumido que o servidor saberá encaminhar o pacote até o domínio do cliente. Essa arquitetura serial de encaminhamento é útil em ambientes onde o ambiente do usuário inclui roaming. Permitindo que pontos de acesso ou servidores AAA por trás de pontos de acesso possam ser configurados para atender um pequeno número de domínios.

Observe que o processamento TTLS da primeira troca de identidade é diferente da forma EAP pura. A máquina de estados TTLS é diferente. No entanto, é esperado que o lado servidor seja capaz de lidar com a inicialização do cliente, porque mesmo o protocolo EAP normal funciona com o cliente inicializado sobre AAA. O lado cliente pode ter várias técnicas de implementação para lidar com as diferenças. Tudo que o protocolo TTLS faz é tornar um pacote TTLS parecido com um EAP-Response/Identity. Isso é similar ao que os autenticadores fazem quando operam entre um cliente e um servidor AAA. Após receber uma mensagem EAP-Response/Identity tunelada o servidor TTLS encaminha para um servidor AAA/H um Response-Request.

O servidor pode responder imediatamente com um Access-Reject, o que faz com que o servidor TTLS encerre a negociação enviando um EAP-Failure para o ponto de acesso. Isso pode ocorrer se o servidor AAA/H não reconhecer a identidade ou não suportar EAP. Neste caso, o servidor também pode responder com um Access-Challenge contendo uma EAP-Request, como o Type e o Type-Data configurados de acordo com o protocolo EAP com o qual o servidor AAA/H deseja autenticar o cliente; como MD5-Challenge, OTP ou GTC.

A autenticação EAP entre cliente e AAA/H procede normalmente, como descrita em [RFC 3748], com o servidor TTLS atuando como um dispositivo pass-through. Cada requisição EAP enviada por AAA/H em um Access-Challenge é tunelada pelo servidor TTLS para o cliente, e cada resposta EAP tunelada para o cliente é decriptada e encaminhada pelo servidor TTLS para o AAA/H na forma de Access-Request. Esse processo continua até que o servidor emita um Access-Accept ou um Access-Reject.

Observe que EAP-TTLS não impõe regras especiais aos pacotes de notificação EAP. Esses pacotes podem então serem utilizados em uma troca tunelada EAP e manter as regras previstas na RFC 3748.

EAP-TTLS fornece um transporte confiável para a troca EAP tunelada. Entretanto, [RFC 3748] presume uma camada de transporte não confiável e irá descartar quaisquer pacotes fora do padrão do protocolo ou que viole uma checagem especifica de um método, pressupondo que esse pacote veio de um atacante. Mas, como o túnel provê uma camada confiável direto para dentro do mecanismo de autenticação EAP, erros que poderiam resultar em descarte silencioso presumidamente são tratados como erros de implementação, quando esses são tratados no túnel. Preferencialmente são descartados de modo silencioso. Todavia, descartar uma mensagem dentro do túnel de modo silencioso pode atrasar o processo de autenticação travando o processo de troca e gerando timeouts para situações que normalmente seriam tratadas como uma falha imediata.

CHAP

O algoritmo CHAP é descrito na RFC 1661; RADIUS descreve formatos de atributos na RFC 2865.

Tanto cliente quanto servidor geram 17 octetos de material criptográfico para desafio usando a cadeia de caracteres "ttls challenge". Esses octetos são:

• CHAP-Challenge [16 octetos]
• CHAP Identifier [1 octeto]

O cliente inicializa CHAP tunelando User-Name, CHAP-Challenge e CHAP-Password em AVPs para o servidor TTLS. O valor do CHAP-Challenge é tirado do material criptográfico usado para desafio. O CHAP-Password é tirado do identificador CHAP tomado a partir do material criptográfico. E a resposta CHAP é calculada de acordo com o algoritmo CHAP.

Após receber essas AVPs o servidor TTLS deve verificar se o valor do desafio CHAP AVP, CHAP Identifier na AVP CHAP-Password são iguais aos valores gerados pelo material criptográfico. Caso não combinem o servidor deve rejeitar o cliente. Caso contrário, ele encaminha as AVPs para o AAA/H na forma de Access-Request. O servidor irá emitir um Access-Accept ou um Access-Reject.

MS-CHAP

O algoritmo MS-CHAP é descrito na RFC 2433 e os atributos são descritos na RFC 2548.

Tanto cliente quanto servidor geram 9 octetos de material criptográfico para desafio usando a cadeia de caracteres "ttls challenge". Esses octetos são:

• MS-CHAP-Challenge [8 octetos]
• Ident [1 octeto]

O cliente inicializa MS-CHAP tunelando User-Name, MS-CHAP-Challenge e MS-CHAP-Response em AVPs para o servidor TTLS. O valor para MS-CHAP-Challenge é tirado do material criptográfico de desafio. O MS-CHAP-Response consiste no Ident, tomado do material criptográfico, sinalizadores configurados de acordo com a preferência do cliente e LM-Response e NT-Response, computados de acordo com o algoritmo MS-CHAP.

Após receber essas AVPs o servidor TTLS deve verificar se o valor da AVP MS-CHAP-Challenge e o valor do Ident na MS-CHAP-Response são iguais aos valores gerados pelo material criptográfico. Caso não combinem o servidor deve rejeitar o cliente. Caso contrário, ele encaminha as AVPs para o AAA/H na forma de Access-Request. O servidor irá emitir um Access-Accept ou um Access-Reject.

MS-CHAP-V2

O algoritmo MS-CHAP-V2 é descrito na RFC 2759. Os atributos RADIUS são descritos na RFC 2548.

Tanto cliente quanto servidor geram 17 octetos de material criptográfico para desafio usando a cadeia de caracteres "ttls challenge". Esses octetos são:

• MS-CHAP-Challenge [16 octetos]
• Ident [1 octeto]

O cliente inicializa MS-CHAP-V2 tunelando User-Name, MS-CHAP-Challenge e MS-CHAP2-Response em AVPs para o servidor TTLS. O valor para MS-CHAP-Challenge é tirado do material criptográfico de desafio. O MS-CHAP2-Response consiste no Ident, tomado do material criptográfico, sinalizadores configurados para zero; Peer-Challenge configurado para um valor aleatório e Response computados de acordo com o algoritmo MS-CHAP-V2.

Após receber essas AVPs o servidor TTLS deve verificar se o valor da AVP MS-CHAP-Challenge e o valor do Ident na MS-CHAP2-Response são iguais aos valores gerados pelo material criptográfico. Caso não combinem o servidor deve rejeitar o cliente. Caso contrário, ele encaminha as AVPs para o AAA/H na forma de Access-Request. O servidor irá emitir um Access-Accept ou um Access-Reject.

Caso a autenticação seja bem sucedida, então AAA/H ira responder com um Access-Accept com o atributo MS-CHAP2-Success. Esse atributo contém uma cadeia de caracteres com 42 octetos usada par autenticar o servidor AAA/H junto ao cliente baseado no Peer-Challenge. O servidor TTLS tunela essa AVP para o cliente. Neste ponto a autenticação ainda não está completa. O cliente ainda precisa aceitar a resposta da autenticação do servidor AAA/H.

Após receber a AVP com o MS-CHAP2-Success, o cliente é capaz de autenticar o AAA/H. Caso a autenticação aconteça, o cliente envia um pacote EAP-TTLS para o servidor TTLS com o campo Data vazio. Após receber um pacote EAP-TTLS vazio do cliente, o servidor TTLS considera que a autenticação MS-CHAP-V2 é bem sucedida.

Se a autenticação falha, o servidor AAA/H responderá com o Access-Challenge contendo um atributo MS-CHAP-Error. Esse atributo contém uma nova Ident e uma cadeia de caracteres com informações adicionais como a razão do erro e se um retry é permitido. O servidor TTLS tunela essa AVP para o cliente. No caso do erro ser causado por uma senha vencida ou caso o cliente queira trocar a senha, o retry será permitido para que o cliente troque sua senha. Nos outros casos a negociação é abandonada.

Caso o cliente não queira trocar a senha ele tunela MS-CHAP-NT-Enc-PW, MS-CHAP2-CPW, e MS-CHAP-Challenge AVPs para o servidor TTLS. A AVP MS-CHAP2-CPW é derivada da nova Ident e do desafio recebido em MS-CHAP-Error AVP. MS-CHAP-Challenge AVP simplesmente ecoa o novo desafio.

Após receber essas AVPs do cliente, o servidor TTLS deve confirmar o valor de MS-CHAP-Challenge AVP, e o valor da Ident do cliente em MS-CHAP2-CPW AVP, para ver se combina com o valor enviado em MS-CHAP-Error AVP. Caso algum deste não combine o cliente deve ser rejeitado. Caso contrário, todas as AVPs são encaminhas ao servidor AAA/H na forma de um Access-Request.

Se a autenticação é bem sucedida, o servidor AAA/H responde com um Access-Accept que contém um atributo MS-CHAP2-Success. Até esse ponto, a negociação procede como descrito acima. O servidor tunela MS-CHAP2-Success para o cliente, o cliente autentica o servidor AAA/H baseado neste AVP. Neste ponto o cliente pode abandonar a negociação ou enviar um pacote EAP-TTLS com o campo Data vazio. Isso faz com que o servidor considere a negociação de autenticação MS-CHAP-V2 bem sucedida.

Observe que AVPs adicionais associadas ao protocolo MS-CHAP-V2 podem ser enviadas pelo servidor AAA/H. Por exemplo, MS-CHAP-Domain. O servidor TTLS DEVE enviar essas informações juntamente com o pacote MS-CHAP-Success.

PAP

O cliente inicializa PAP tunelando User-Name e User-Password AVPs para o servidor TTLS.

Normalmente, em RADIUS, User-Password é preenchida com nulos para um múltiplo de 16 octetos, então encriptado usando uma senha compartilhada e outro pacote de informações. Todavia, o cliente EAP-TTLS não faz essa encriptação RADIUS, já que essas variáveis não estão disponíveis. Isso não é considerado uma fraqueza de segurança já que senha será encriptada via TLS de qualquer modo. Mas o preenchimento com zeros ajuda a ofuscar o tamanho da senha.

Após receber essas AVPs do cliente, o servidor TTLS encaminha para o servidor AAA/H um pacote RADIUS do tipo Access-Request. O servidor TTLS pode encriptar o atributo User-Password usando a chave secreta compartilhada entre o servidor TTLS e AAA/H e incluí-la neste Access-Request. O servidor AAA/H pode aceitar ou rejeitar a requisição de acesso. O servidor TTLS completa o processo de negociação enviando um EAP-Success ou EAP-Failure para o ponto de acesso através de um protocolo de portadora.

O servidor AAA/H pode também responder à requisição com um Access-Challenge. O servidor TTLS tunela essas AVPs para o servidor AAA/H e envia ao cliente. Após receber esse desafio, o cliente tunela User-Name e User-Password novamente, agora User-Password terá um novo valor em resposta ao desafio. Esse processo continua até que AAA/H aceite ou rejeite o cliente.

Ao menos uma das AVPs tuneladas para o cliente mediante desafio DEVE ser do tipo Reply-Message. Normalmente isto é enviado por AAA/H como parte do desafio. Entretanto, se o AAA/H não enviou uma Reply-Message, o servidor TTLS deve fazê-lo, com o valor nulo. Isso permite ao cliente determinar que uma resposta do desafio é requerida.

Observe que, se o AAA/H incluir a Reply-Message como parte de um Access-Accept ou Access-Reject, o servidor TTLS não tunela essa AVP ao cliente. Uma vez que, esse e outros AVPs enviados pelo AAA/H como parte de um Access-Accept ou Access-Reject são enviados ao ponto de acesso através de um protocolo de portadora.

Executando múltiplas autenticações

Em alguns casos, pode ser necessário que o usuário realize múltiplas autenticações. Por exemplo, um AAA/H pode inicialmente autenticar um usuário por senha e por um controle de símbolo (token card).

O servidor AAA/H pode executar autenticações adicionais usando EAP, simplesmente emitindo um EAP-Request com um novo tipo EAP assim que autenticação anterior estiver terminada. Cada novo método EAP apresentado ao servidor está sujeito a nova autenticação independente da anterior.

Por exemplo, um servidor AAA/H deseja realizar uma autenticação usando o método MD5-Challenge seguido de GTC. Então, deve primeiro emitir um pacote EAP-Request/MD5-Challenge e receber a resposta. Caso a resposta seja satisfatória, então um pacote EAP-Request/GTC é enviado. O cliente somente será autenticado, se ambas as respostas forem satisfatórias.

A totalidade das trocas EAP nos casos de múltiplas autenticações é compreendida como uma única troca EAP. Neste caso, cada requisição subseguinte DEVE conter um identificador EAP distinto do anterior já que uma somente começa quando a outra termina.

O identidade do par enviado na EAP-Response/Identity que iniciou a seqüência EAP será aplicada a cada uma das autenticações seqüenciais, e na ausência de um perfil padrão da aplicação, outros pedidos de identidade NÃO devem ocorrer.

As condições para que múltiplas autenticações sejam usadas dependem da configuração (política) tanto do lado servidor quanto cliente.

Assim, qualquer das partes pode exigir que pelo menos uma ou mesmo todas as autenticações anteriores tenham sido bem sucedidas, como uma condição de sucesso para o conjunto das autenticações.

Cada método EAP é implementado de modo a executar por completo. Caso o servidor abandone um método para executar outro, o resultado disso sobre o comportamento do cliente não é previsto neste documento, já que é uma questão de política.

Note que nem sempre é possível utilizar o mesmo método EAP duas vezes, pois como o tipo do método não muda, não é possível determinar sobre qual rodada uma resposta EAP está falando.

Certos métodos EAP, como EAP-TLS, usam um bit de início para definir a primeira requisição. Isso permite que cada nova autenticação usando o mesmo tipo seja distinta da anterior.

Outros métodos como MS-CHAP-V2 são encerrados de uma maneira muito bem definida. Permitindo que uma segunda rodada de autenticação do mesmo tipo não seja alvo de ambigüidades. Embora, usar o mesmo método repetidas vezes seja pouco provável (e desnecessário!) as implementações devem saber lidar com isso para evitar ambigüidades.

Suporte a autenticação tunelada obrigatória

Para garantir interoperabilidade, e na ausência de um perfil padrão, uma implementação que siga essa especificação DEVE implementar EAP como um método de autenticação tunelado e MD5-Challenge como um tipo pertencente a EAP. Embora toda implementação deve permitir que qualquer método tunelado, incluindo EAP ou outros, possa ser desativado por uma decisão administrativa no cliente ou no servidor TTLS.

Do mesmo modo deve ser permitido ao administrador configurar o uso da autenticação tunelada, mesmo sem o bit (M – Mandatory) estar habilitado em uma AVP.

Sugestões adicionais de suporte a protocolos tunelados

As informações nessa sessão tem caráter não normativo servindo como um guia baseado na experiência dos autores e revisores dessa especificação.

Os métodos a seguir são comumente usados, e servidores que desejam interoperabilidade através de múltiplos meios devem considerar a implantação dos seguintes métodos:

• PAP (para autenticação por senha e símbolos – token)
• MS-CHAP-V2
• EAP-MS-CHAP-V2
• EAP-GTC