O modelo arquitetônico de rede para EAP-TTLS e o tipo de segurança que é implementada em cada dispositivo é exemplificada na figura a seguir.



O modelo acima descreve as entidades lógicas, e pode não corresponder aos componentes de rede reais. Por exemplo, o servidor TTLS e o AAA/H podem ser uma única entidade na prática. O diagrama ilustra a divisão de trabalho proposta para cada entidade. E de forma geral mostra como um sistema distribuído pode ser construído. Embora, na prática, esse sistema seja sempre menos complexo.

Protocolos de portadora

As entidades citadas neste documento devem ser capaz de comunicarem entre si usando protocolos de portadora que possam encapsular EAP. O cliente e o ponto de acesso se comunicam usando tipicamente uma camada de ligação como PPP ou EAPOL. Já o ponto de acesso, o servidor TTLS e o servidor AAA/H se comunicam usando um protocolo como RADIUS ou Diameter.

EAP, e portanto EAP-TTLS, devem ser iniciados através de um protocolo de portadora entre o cliente e o ponto de acesso. Em PPP, por exemplo, EAP é iniciado quando o ponto de acesso manda um pacote com uma requisição EAP/identity para o cliente.

O material criptográfico usado para encriptar e autenticar a conexão de dados entre o cliente e o ponto de acesso é devolvido implicitamente entre o cliente e o servidor TTLS como o resultado da negociação EAP-TTLS. Esse material criptográfico é transportado entre o ponto de acesso e o servidor TTLS usando um protocolo de portadora tipo AAA.

Relacionamentos de segurança

O cliente e o ponto de acesso não possuem uma relação de segurança pré-existente. Já o ponto de acesso, o servidor TTLS e o servidor AAA/H cada um presume uma associação pré-existente com a entidade com a qual irá se comunicar. Com RADIUS, por exemplo, é necessário o cadastramento de uma chave secreta compartilhada entre o servidor e o NAS. Esses relacionamentos são essenciais para a segurança, pois permitem uma distribuição segura da chave.

Um cliente e seu servidor AAA/H possuem um relacionamento de segurança baseado nas credenciais do usuário.

Um cliente e um servidor TTLS podem ter um relacionamento de segurança de "uma via", baseado no fato que o servidor possui uma chave privada garantida por um certificado, no qual o cliente confia. Esse relacionamento também pode ser mútuo, baseado nos certificados de ambas as partes.

Mensagens

O cliente e o ponto de acesso iniciam uma conversação EAP para negociar o acesso do cliente a rede. Tipicamente, o ponto de acesso envia uma requisição EAP solicitando identidade. Esse responde com um EAP-Response/Identity. Observe que o cliente não precisa incluir a identidade do usuário real nestes pacotes EAP-Response/Identity que são somente para fins de encaminhamento. E isso irá acontecer até que o canal criptográfico esteja estabelecido. Neste momento, o ponto de acesso atua como um dispositivo de pass-through, permitindo que o EAP-TTLS cliente negocie diretamente com o TTLS servidor.

Durante a primeira fase da negociação, a troca de pacotes (handshake) TLS é usada para autenticar o servidor TTLS junto ao cliente. E opcionalmente, para autenticar o cliente no servidor. Toda essa negociação de autenticação depende de certificados de chaves pública/privada. Como resultado desse handshake, agora o servidor e o cliente possuem um conjunto de materiais criptográficos que são compartilhados e concordam sobre a cifra da camada TLS, com a qual será realizada a comunicação EAP-TTLS subseguinte.

Durante a segunda fase da negociação, cliente e servidor TTLS usam o canal seguro estabelecido pela negociação TLS como um túnel para a troca de informações encapsuladas, no formato de pares atributo-valor, para realizar funções adicionais como a autenticação (de uma via ou mútua), validação da integridade do cliente e configuração, fornecimento de informação necessária para a conectividade de dados, etc.

Caso a autenticação tunelada do cliente seja realizada, o servidor TTLS desfaz o tunelamento e encaminha as informações de autenticação para o servidor AAA/H. No caso do servidor AAA/H fazer um desafio, o servidor TTLS "tunela" o desafio de volta ao cliente. O servidor AAA/H pode ser um dispositivo legado que não sabe absolutamente nada sobre EAP-TTLS. Ele só precisa ser capaz de autenticar o cliente baseado em um protocolo de comunicação normalmente usado.

O material criptográfico para a subseguinte conexão de dados entre o cliente e o ponto de acesso (MSK e EMSK, veja sessão 8) é gerado baseado na informação secreta desenvolvida durante o handshake TLS entre o cliente e o servidor TTLS. Após a conclusão bem sucedida da autenticação, o servidor TTLS pode transmitir esse material criptográfico para o ponto de acesso, usando a encriptação estabelecida pela associação entre esses dispositivos. (No protocolo RADIUS, uma chave compartilhada!).

Neste ponto, cliente e ponto de acesso possuem material criptográfico compartilhado que pode ser usado para criptografar a troca de dados entre eles.