Após o handshake TLS, a informação pode ser "tunelada" entre o cliente e o servidor TTLS através do uso de pares de atributo-valor (AVPs) encriptados com a camada de gravação de TLS.

O formato AVP escolhido para o protocolo EAP-TTLS é compatível com o formato do protocolo Diameter. Isso não representa um requerimento de que todos os dispositivos ou servidores participantes tenham suporte para Diameter durante a negociação EAP-TTLS. O uso desse formato é meramente uma conveniência. Diameter é um "superconjunto" de RADIUS, incluindo TODOS seus espaços de nome e atributos.

Todavia, Diameter não limita o tamanho do AVP, como faz RADIUS, mas por outro lado RADIUS é um protocolo AAA com maior abrangência (grande número de usuários) e amplo suporte para muitos métodos de autenticação por senha, incluindo EAP.

A representação do campo data de um AVP em EAP-TTLS deve ser idêntica como definido em Diameter.

Ao usar uma definição de espaço de nomes comum a RADIUS/Diameter permite que o servidor TTLS traduzir facilmente entre as AVPs usadas pelos clientes para se comunicarem e o protocolo pelos servidores AAA que são mais utilizados. Além disto, isso fornece um mecanismo bem entendido que permite aos vendedores que estendam o espaço de nomes de seus requerimentos particulares.

É esperado que os mesmos códigos usados pelas AVPs em EAP-TTLS possuirão o mesmo significado em EAP-TTLS, fazendo as mesmas funções como fazem em Diameter, e por extensão em RADIUS.

Entretanto, apesar de EAP-TTLS usar o mesmo formato dos códigos das AVPs e a sintaxe de Diameter, a semântica pode ser diferente, e a maioria das AVPs de Diameter não são bem definidas em EAP-TTLS. Um relação das AVPs que podem ser usadas em EAP-TTLS e sua semântica podem ser encontradas na sessão 13.

Um servidor TTLS copiando AVPs entre uma troca EAP-TTLS e Diameter ou RADIUS NÃO DEVE fazer qualquer suposição sobre AVPs cujo uso, tanto em EAP-TTLS ou no protocolo por trás que ele não entende, e, portanto NÃO DEVE copiar essa AVP entre o EAP-TTLS e Diameter/RADIUS, a menos que a semântica realmente seja compreendida nos dois contextos.

O formato AVP

O formato de um AVP é demonstrado pela figura abaixo. Todos os itens são em rede, ou no formato big-endian. Ou seja, o octeto mais significativo está representado da esquerda para direita.



O campo AVP Code é formado por quatro octetos e, combinado com o valor de campo Vendor-ID, se presente, identifica um atributo de modo singular. Os primeiros 256 códigos AVP representam os atributos definidos em RADIUS [RFC 2865], os atributos acima são definidos em Diameter [RFC 3588].

Sinalizadores AVP

Um campo de sinalizadores formado por um octeto, e que fornecem informações suficientes para interpretar o AVP.

O bit (V) - Vendor Specific - indica a presença de um campo Vendor-ID (normalmente opcional). Quando configurado como 1, o Vendor-Id está presente e o AVP é interpretado de acordo com o espaço de nomes definido pelo vendedor indicado no campo Vendor-ID.

O bit (M) - (Mandatory) - indica quando o suporte para AVP é requerido. Quando desativado (0), indica que o AVP pode ser seguramente ignorado caso a parte que esteja recebendo não entenda ou não suporte esses AVP. Quando ativado (1), indica que a parte que está recebendo o AVP deve falhar durante a negociação caso não entenda um AVP. Para um servidor TTLS isso implica em retornar um pacote EAP-Failure para o cliente, o que resulta no abandono da negociação.

Os bit (R) - (Reservados) não são utilizados e devem ser configurados como zero pelo emissor e ignorado pelo receptor.

O campo AVP Length é composto por três octetos, e indica o comprimento do AVP incluindo o AVP Code, AVP Length, AVP Flags, Vendor-Id ( se presente) e o campo Data.

O campo Vendor-Id estará presente se o sinalizador (V) estiver ativo no campo de sinalizadores. Formado por quatro octetos, contém um valor que representa o código SMI - Network Management Private Enterprise Codes - atribuído pela IANA e atualmente disponível no portal da entidade em:

• http://www.iana.org/assignments/enterprise-numbers

Os vendedores definem seus próprios AVPs mas devem manter consistência para a utilização destes com o espaço de nomes usado por RADIUS, Diameter e EAP-TTLS.

Um Vendor-ID igual a zero é equivalente a ausência do parâmetro.

Observe que o sinalizador (M) mandatório fornece um modo para estender as funcionalidades de EAP-TTLS, enquanto preserva a compatibilidade quando essa é desejada. Ao ativar ou desativar (M) como o AVP apropriado, a parte inicializa a função para a outra parte indicando se o suporte a essa função é opcional ou requerido.

Seqüências AVP

Os dados encapsulados na camada de gravação por TLS devem consistir inteiramente de uma seqüência de zero ou mais AVPs. Cada AVP deve começar na borda onde termina o anterior. O primeiro AVP terá quatro octetos de comprimento. Caso um AVP não seja múltiplo de quatro, será preenchido com zeros até seu limite. Neste caso a propriedade AVP Length não inclui esse preenchimento.

Orientações para máxima compatibilidade com servidores AAA

As seguintes sugestões são feitas para máxima compatibilidade:

AVPs que NÃO são Vendor-Specific destinadas a serem utilizadas com servidores AAA devem ser selecionadas de um conjunto de atributos definidos por RADIUS. Esses atributos terão o código menor que 256. Isso mantém a compatibilidade tanto com RADIUS quanto com Diameter.

AVPs que SÃO Vendor-Specific destinadas a serem utilizadas com servidores AAA devem ser definidas em termos de RADIUS. Atributos Vendor-Specific de RADIUS são traduzidos para Diameter (e, conseqüentemente para EAP-TTLS) automaticamente. O inverso não é verdadeiro.