A negociação EAP-TTLS compreende duas fases: A fase do handshake TLS e a fase do túnel TLS.

Durante a primeira fase, TLS é usado para autenticar o servidor TTLS junto ao cliente, e opcionalmente, o cliente junto ao servidor. A fase 1 resulta na ativação de uma conjunto de cifras, que irão permitir que a fase 2 prossiga seguramente usando a camada de gravação TLS. (Observe que o tipo e o grau da segurança na fase 2 depende do conjunto de cifras negociadas na fase 1. Caso um conjunto NULO de cifras seja negociado, a segurança será NULA).

Durante a fase 2, a camada de gravação TLS é usada para criar um túnel entre os clientes e o servidor TTLS usado para realizar qualquer uma das funções como: autenticação, validação da integridade, negociação de capacidades usadas na comunicação de dados, distribuição de chaves, comunicação da contabilidade etc.

Informação entre cliente e servidor TTLS é trocada via AVPs compatíveis com RADIUS ou Diameter. Qualquer função implementada via AVPs será facilmente configurada.

EAP-TTLS especifica como a autenticação do usuário pode ser feita durante a fase 2. O usuário pode ser auto-autenticar por EAP, ou usar um protocolo legado como PAP, CHAP, MS-CHAP ou MS-CHAP-V2. Então, a fase 2 pode não ser necessária em todos os casos, desde que o usuário possa ser autenticado via autenticação mútua do protocolo TLS. Na fase 2 podem ser realizadas outras funções além da autenticação. Esse documento não descreve quaisquer funções; entretanto, qualquer organização pode definir funções que possam ser realizadas através do uso das AVPs apropriadas.

Fase 1 - Handshake

Na fase 1, o handshake do protocolo TLS é usado para autenticar o servidor TTLS junto ao cliente, e opcionalmente, o cliente junto ao servidor.

O servidor TTLS inicializa o método EAP-TTLS com um pacote EAP-TTLS/Start, que é uma EAP-Request com tipo igual a EAP-TTLS e o bit S (Start) ativado. Isso diz ao cliente que ele deve iniciar o handshake enviando uma mensagem ClientHello.

Pacotes EAP continuam a serem trocados entre o cliente e o servidor TTLS para completar o handshake TLS, como descrito na RFC 5216. A fase 1 é completada quando o cliente e o servidor TTLS trocam as mensagem ChangeCipherSpec e Finished.

Após esse ponto qualquer informação adicional pode ser solidamente enviada pelo túnel.

Como parte do handshake do protocolo TLS, o servidor TTLS irá enviar seu certificado, junto com uma cadeia de certificados que conduzem até o certificado de uma CA de confiança. O cliente necessita então ser configurado com o certificado da entidade certificadora para que possa realizar a autenticação. Se a autenticação do cliente exige um certificado, então esse cliente deve ter emitido um certificado e deve ter a chave privada associada a esse certificado.

Fase 2 - O Túnel

Na fase 2, a camada de gravação de TLS é usada para "tunelar" informações de modo seguro entre o cliente e o servidor TTLS. Essa informação é encapsulada em seqüências de AVPs, cuja utilização e formato serão descritos nas sessões seguintes.

Qualquer tipo de informação pode ser trocada na fase 2, de acordo com os requerimentos do sistema. O cliente começa a fase 2 trocando informações codificadas em uma seqüência de AVPs em texto puro diretamente para a camada de gravação TLS. Se a seqüência de AVP inclui informações de autenticação, essa informação é encaminhada para o servidor AAA/H usando um protocolo de portadora AAA. Observe que tanto o servidor AAA/H e o EAP-TTLS podem ser o mesmo, neste caso a informação é processada localmente.

O servidor TTLS pode responder com sua própria seqüência de AVPs. O servidor TTLS passa a seqüência para a camada de gravação de TLS para encriptação, e envia o resultado dos dados para o cliente. Por exemplo, um servidor TTLS pode encaminhar um desafio de autenticação recebido para um servidor AAA/H.

Esse processo continua até que o servidor aceita ou rejeita o cliente, resultando em um servidor TTLS completando a negociação EAP-TTLS e indicando sucesso ou falha para o encapsulamento do protocolo EAP.

O servidor TTLS distribui o material criptográfico além de outras informações para o ponto de acesso no mesmo pacote EAP-Success com mensagem, envidado por um protocolo de portadora do tipo AAA.

A informação sobre identidade

A identidade do usuário é fornecida durante a fase 2, onde é protegida pelo túnel TLS. No entanto, antes de iniciar a autenticação TTLS, o cliente receberá um pacote EAP-Response/Identity que faz parte do protocolo EAP, contento um nome de usuário (username) em texto puro. Para preservar o anonimato do usuário contra escutas, esse pacote não deve incluir o nome real do usuário; em vez disso, o parâmetro será configurado com espaço em brancos ou algo como "anônimo", substituindo o nome real.

Todavia, por questões de encaminhamento de pacotes, pode ser que o nome NAI inclua o endereço do domínio do usuário. Esse endereço pode ser usado para fins de roteamento de pacotes de resposta.

Observe que no momento em o pacote inicial EAP-Response/Identity é enviado o método EAP ainda está a ser negociado. Neste caso, se o cliente está disposto a negociar um método EAP que não suporta anonimato, então o cliente pode incluir o nome do usuário (username) no pacote EAP-Response/Identity para satisfazer as necessidades desses métodos.

PiggyBacking

***************************************************************
NT: Segundo [Tanenbaum] PiggyBacking (superposição) é o nome da técnica usada para enviar várias confirmações em conjunto. Como uma rajada de configurações. Uma das vantagens é reduzir o número de quadros enviados pela rede.
***************************************************************

Embora seja conveniente descrever as mensagens EAP-TTLS em termos de duas fases, algumas vezes é requerido que um único pacote EAP-TTLS contenha mensagens de ambas as fases. Um exemplo disso ocorre quando há piggybacking em relação a parte que completa o handshake e tem AVPs para enviar.

Outro exemplo, é quando está negociando a retomada da sessão TLS, o servidor TTLS envia as mensagens ChangeCipherSpec e Finished primeiro e o cliente então envia suas próprias mensagens com esses parâmetros para concluir o handshake. Se o cliente tem outras mensagens AVPs ou de autenticação para enviar ao servidor TTLS, ele deve "tunelar" essas mensagens no mesmo pacote imediatamente após a mensagem Finished. Se isso falha, o servidor TTLS irá (incorretamente) assumir que o cliente não tem mais mensagens AVPs para enviar, e o resultado da negociação pode ser afetado.

O reinício de uma sessão

Quando um cliente e um servidor TTLS que tenham negociado anteriormente uma sessão, e desejam começar outra nova negociação EAP-TTLS, ambos podem concordar em apenas reiniciar uma sessão anterior.

A principal vantagem disso, é que o tempo (esforço computacional) necessário para retomar a sessão é menor que o esforço para criar uma nova. Essa situação pode ocorrer quando um cliente se conecta a um novo ponto de acesso, ou quando o ponto de acesso requer re-autenticação de um cliente atualmente conectado.

A retomada da sessão é feita utilizando o mecanismo padrão de TLS. O cliente sinaliza sua vontade de retomar a sessão incluindo o valor de Session ID, da sessão que deseja retomar, na mensagem ClientHello.

Se o servidor TTLS decide que não aceita retomar a sessão, ele simplesmente não faz "eco" do Session ID, fazendo com que uma nova sessão seja negociada. Isso ocorre se o servidor TTLS está configurado para não retomar sessões ou se essa sessão está considerada obsoleta. O servidor pode considerar uma sessão obsoleta baseado em sua própria configuração, ou em informações sobre limites das sessões recebidos de AAA/H (por exemplo, o atributo RADIUS, Session-Timeout).

Autenticações "tuneladas" são realizadas de modo que a simples presunção do conhecimento da chave "mestre" seja suficiente para permitir a retomada da sessão. Isso permite que a retomada da sessão ocorra sem qualquer mensagem entre o servidor TTLS e o servidor AAA/H. Caso o servidor AAA/H exija que a sessão seja re-autenticada periodicamente, ele deve indicar isso ao servidor TTLS onde a sessão foi originalmente estabelecida, por exemplo, através do atributo RADIUS Session-Timeout.

Um cliente pode enviar outros AVPs solicitando a retomada da sessão para ativar funções de não-autenticação. Caso não faça, o servidor TTLS, se assim desejar, PODE enviar AVPs para o cliente para iniciar funções de não-autenticação. Ou ainda, PODE simplesmente completar a negociação EAP-TTLS e indicar sucesso ou falha para o protocolo EAP.

O servidor TTLS deve reter as informações sobre autorização usadas por um servidor AAA/H durante a retomada da sessão. A sessão retomada deve operar sob as mesmas autorizações da sessão original, e o servidor TTLS deve estar preparado para enviar a informação apropriada de volta ao ponto de acesso. Informações sobre autorização podem incluir parâmetros como tempo máximo da sessão, largura de banda máxima permitida, informações sobre filtragem de pacotes e outras. O servidor TTLS é responsável por modificar valores baseados em passagem de tempo, com Session-Timeout, apropriadamente para cada sessão retomada.

O servidor TTLS não pode permitir a retomada de uma sessão que não tenha resultado em sucesso na autenticação do usuário na fase 2. A conseqüência de falhas de implementação nessa característica pode ser CATASTRÓFICA, um atacante simplesmente inicia uma sessão que tem sucesso na fase TLS, mas falha na fase 2de autenticação, em seguida ele simplesmente retoma a sessão e obtém acesso à rede.

Determinando quando entrar na fase 2

Entrar na fase 2 é opcional, e pode ser uma decisão tanto do cliente quanto do servidor TTLS. Se já não há mais troca de informações sobre autorização ou outras informações necessárias para autenticar após o fim da fase 1, então é possível concluir com êxito a negociação EAP-TTLS sem nunca entrar na fase 2 ou enviar qualquer AVP sobre tunelamento.

Cenários em que nunca se entra na fase 2 são:

• Retomada de uma sessão, sem necessidade de trocar qualquer informação adicional.
• Autenticação de um cliente utilizando um certificado durante a fase 1, sem qualquer tipo de informação adicional necessária.

O cliente sempre terá a primeira oportunidade de iniciar a fase 2 ao ter completado a fase 1. Caso o cliente não tenha mais AVPs para enviar, então ele envia um Acknowledgement (ver sessão 9.2.3) caso o servidor TTLS enviar uma mensagem indicando o fim da fase 1, ou simplesmente não faz PiggyBacking de uma mensagem da fase 2 quando se questiona o final da fase 1 (do mesmo modo quando ocorre a retomada da sessão).

Caso o cliente não inicie a fase 2, o servidor TTLS, opcionalmente, pode então completar a negociação EAP-TTLS sem entrar na fase 2 ou simplesmente iniciar a fase 2 "tunelando" AVPs para o cliente.

Por exemplo, suponha uma sessão retomada com sucesso e que ocorra na fase 1. As seguintes seqüências são possíveis:

• Nenhum dos lados tem informações adicionais para trocar. O cliente completou a fase 1 sem fazer PiggyBacking de AVPs da fase 2, então o servidor indica o sucesso do encapsulamento do protocolo EAP, sem necessidade de entrar na fase 2.
• O cliente não tem informações adicionais para enviar, entretanto, o servidor as tem. O cliente completou a fase 1 sem fazer PiggyBacking de AVPs da fase 2, mas o servidor estende a negociação de EAP-TTLS para a fase 2, enviando AVPs pelo túnel na próxima mensagem EAP-TTLS.
• O cliente não tem informações adicionais para enviar, e faz PiggyBacking de AVPs da fase 2 na mensagem final da fase 1, isso estende a negociação para a fase 2.

A versão TLS

A versão 1.0 de TLS [RFC 2246], a 1.1 [RFC 4346] ou qualquer outra superior (no futuro!) PODE ser usada por EAP-TTLS. Já que TLS provê seu próprio mecanismo de negociação de versão. Para máxima operacionalidade as implementações de EAP-TTLS devem suportar TLS versão 1.0.

O uso da função pseudo-randômica por TLS

O método EAP-TTLSv0 utiliza a PRF (Pseudo-Random Function) ou Função Pseudo-Randômica para gerar material para criptografia (sessão 8) e para gerar desafios implícitos para certos métodos de autenticação (sessão 11.1). A PRF usada nestes casos é o PRF do TLS, usada também durante o handshake da negociação que inicia as trocas de pacotes EAP-TTLS.

A função PRF é definida no protocolo TLS (1.0/1.1) e qualquer implementação baseada nessas versões deve fazer uso destas funções. É esperado que versões futuras ou extensões de TLS permitam que funções PRF alternativas sejam negociadas. Uma função alternativa pode ser especificada ou se uma função TLS foi negociada durante o handshake, então essa função alternativa será usada nos processamentos de EAP-TTLSv0 no lugar das funções originais TLS 1.0/1.1.

Esse especificação define uma função PRF a ser usada por TLS como:

PRF-nn (secret, label, seed)

Onde:

• nn é o número de octetos gerados
• secret é uma chave secreta
• label é uma cadeira de caracteres (string) sem terminação com um nulo
• seed é uma seqüência binária

As funções PRF de TLS 1.0/1.1 tem a saída invariante independente do número de octetos gerados. Entretanto, é possível que um PRF alternativa inclua o tamanho da seqüência de saída como entrada para a função PRF. Isso significa que gerando 32 octetos ou 64 octetos com os mesmos parâmetros de entrada não resulta que os 32 primeiro octetos de cada cadeia serão idênticos. Por essa razão, o PRF é sempre especificado como um "nn", que indica o número de octetos gerados.