Métodos de Autenticação de Usuários em Telnet e FTP


Hélder Garcia
Departamento de Informática
Universidade Federal de Pernambuco
Novembro de 1996

Sumário

    Introdução
.............................................. 1
    Telnet Authentication Option
.............................................. 2
    Secure RPC Authentication (SRA)
.............................................. 4
      Incorporação em Telnet
.............................................. 5
      Vantagens e Desvantagens
.............................................. 6
    Conclusão
.............................................. 6
    Referencias
.............................................. 7

Introdução

No momento de uma conexão Telnet (ver [RFC764]) ou FTP (ver [RFC959]), o cliente deve ser autenticado pelo respectivo servidor. Essa autenticação exige a transmissão do username e da password do usuário. A transmissão de senhas através da rede atualmente feita por Telnet e FTP é feita utilizando simplesmente "texto puro", ou seja, sem qualquer tipo de proteção contra leituras desautorizadas. Essas leituras são possíveis e até mesmo relativamente fáceis por meio de ferramentas como tcpdump e etherfind. Isso expõe inclusive a conta root a um invasor indesejado.

A implementação do Telnet permite hoje algumas técnicas de autenticação. Podemos citar dentre estes estas o Telnet Authentication SPX (ver [RFC1412]), Kerberos Authentication Version 4(ver [RFC1411]), Kerberos Authentication Version 5 (ver [RFC1510]) e RSA.

Este documento trata das alterações realizadas no protocolo Telnet para suportar técnicas de autenticação e de uma nova proposta ainda nao incorporada a lista de tipos do Telnet chamada "Secure RPC Authentication (SRA)". Essas mudanças no Telnet podem ser diretamente portadas para o FTP, pois ele usa as mesmas regras que Telnet para o envio de comandos via conexão de controle.



[Page 1]

Telnet Authentication Option

A adaptação do Telnet para implementar métodos de autenticação foi feita através da inclusão de uma opção chamada "Authentication Option" (ver [RFC1416]) e alguns comandos para negociar o tipo de autenticação, como o método e o direcionamento da operação.

A negociação é efetuada através do uso das seguintes mensagens:

  • IAC WILL AUTHENTICATION

    Este comando é enviado pelo cliente indicando que ele deseja utilizar uma técnica de autenticação segura.

  • IAC DO AUTHENTICATION

    Este comando é enviado pelo servidor indicando que ele deseja que o cliente utilize uma técnica de autenticação segura.

  • IAC WONT AUTHENTICATION

    É uma resposta negativa a um "DO AUTHENTICATION" do cliente indicando que ele não entende esta opção.

  • IAC DONT AUTHENTICATION

    É uma resposta negativa a um "WILL AUTHENTICATION" do servidor indicando que ele não entende esta opção.

    Por restrição de projeto, a negociação só pode ser feita do servidor para o cliente. O servidor deve mandar um DO e o cliente um WILL ou WONT. Em qualquer caso, se o servidor receber um DO, ele deve responder com um WONT, e se o cliente receber um WILL, ele deve responder com um DONT.

    Após estabelecido que os dois lados entendem a opção, os seguintes comandos (ou sub-options) são usados para caracterizar o tipo de autenticação e o direcionamento:

  • IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE

    Somente o servidor pode enviar este comando. Neste comando o servidor envia uma lista dos tipos de autenticação suportados por ele para o cliente, em ordem de preferencia, o primeiro tem a maior preferencia e o último, a menor. Esta lista está em authentication-type-pair-list. É uma lista ordenada de pares do tipo (type, modifier) de acordo com a tabela a seguir:






    [Page 2]
    Types
    NULL
    KERBEROS_V4
    KERBEROS_V5
    SPX
    RSA
    LOKI

    Modifiers AUTH_WHO_MASK
    AUTH_CLIENT_TO_SERVER
    AUTH_SERVER_TO_CLIENT

    Modifiers AUTH_HOW_MASK
    AUTH_HOW_ONE_WAY
    AUTH_HOW_MUTUAL

    Um authentication-pair é composto de dois octetos. O primeiro indica o tipo ou método da autenticação e no segundo são utilizados dois campos de um bit cada que indicam o bit AUTH_WHO_MASK e o bit AUTH_HOW_MASK, possibilitando quatro alternativas descritas ao final desta seção.

  • IAC SB AUTHENTICATION IS authentication-type-pair <auth-data> IAC SE

    Somente o cliente pode enviar este comando. Neste caso ele está mandando informações a respeito do tipo de autenticação escolhido dentre a lista enviada pelo servidor. O tipo escolhido está em authentication-type-pair e as informações em <auth-data>. Caso o cliente não conheça nenhum dos tipos listados pelo servidor, ele deve enviar um tipo NULL no comando IS. Neste caso, o servidor pode decidir fechar a conexão.

  • IAC SB AUTHENTICATION REPLY authentication-type-pair <auth-data> IAC SE

    Somente o servidor pode enviar este comando. Aqui ele está mandando uma resposta às informações recebidas em um comando IS anterior.


    O modifier pode indicar uma das quatro combinações abaixo:

    [Page 3]

    É importante notar que o esquema de opções do Telnet permite manter a compatibilidade entre sistemas que suportam autenticação e outros mais antigos que não suportam, pois estes últimos simplesmente recusam a negociação de qualquer opção que desconheçam, mandando um DONT ou WONT para o outro lado da conexão. O lado que recebe a negativa passa a trabalhar do modo original, sem a opção a qual tentou negociar, e sem a geração de qualquer tipo de erro.

    Secure RPC Authentication (SRA)


    Este método utiliza Secure RPC Code para cálculo de chaves e foi publicado em artigo da USENIX (ver [USENIX]) em 93. O algoritmo utilizado é baseado no método de Diffie-Hellman (DES) e sua especificação pode ser encontrada em [    RFC1057], que é o RFC que define RPC. Secure RPC normalmente utiliza um keyserver que faz armazenamento e gerenciamento de senhas criptografadas. Entretanto, neste método, isto é simplificado através do cálculo de uma nova chave randômica a cada autenticação Telnet ou FTP.

    A sequencia de fluxo de dados é basicamente a seguinte:

    Cliente Servidor
    Calcula PKA, SKA Calcula PKB, SKB
    Envia PKA ao servidor Envia PKB ao cliente
    Calcula chave comum KAB Calcula chave comum KAB.
    Envia KAB(User, Password)
    Recebe e processa KAB'(User, Password)

    De acordo com o Secure RPC Code, as chaves são inteiros de 192 bits calculados da seguinte forma:

    SK (secret key) = número randômico
    [Page 4]
    PK (public key) = (baseSK) mod modulus

    onde base = 3
    e modulus = d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b

    Visto que a exponenciação é comutativa, amobos os lados podem calcular confidencialmente a chave comum KAB:

    Servidor: KAB = (PKASKB) mod modulus

    Cliente: KAB = (PKBSKA) mod modulus

    Secure RPC utiliza os 64 bits centrais de KAB para criptografia DES. O cálculo de KAB é razoavelmente seguro, uma vez que requer pelo menos uma chave secreta, que não é colocada na rede.

    Incorporação em Telnet


    A incorporação ao protocolo Telnet exige a adição do tipo SRA à lista de métodos vista anteriormente, cujo código é passado no par (type, modifier). Adições a essa lista devem ser registradas com a     Internet Assigned Numbers Authority (IANA).

    A negociação é feita normalmente utilizando DO, WILL, DONT, WONT.

    SRA tem cinco subopções de comandos: KEY, USER, PASS, ACCEPT, e REJECT. O fluxo de dados de uma autenticação completa é mostrado abaixo:


    [Page 5]

    Vantagens e Desvantagens


    O autor destaca como vantagens deste método:

  • A informação de autenticação do usuário é enviada criptografada com uma chave DES só de ida;
  • O método não precisa de keyservers externos;
  • É compatível com os métodos já existentes;
  • É razoavelmente rápido;
  • É facilmente implementável;
  • Todo o código fonte está disponível publicamente.

    E como desvantagens:

  • Ele não prove autenticação do servidor pelo cliente, ou seja, apenas o servidor pode autenticar o cliente e não vice-versa;
  • Secure RPC é sujeito a ataques com cálculos logarítmicos, embora estes não sejam triviais;
  • O algoritmo de Diffie-Hellman é patenteado.

    Conclusão


    A implantação de um sistema de autenticação criptografada em uma rede é um investimento que deve ser medido de acordo com a relação custo-benefício.
    Os vários métodos disponíveis oferecem uma ampla faixa de níveis de segurança, a qual cresce levando junto a si os parâmetros de complexidade e custo de processamento. Ou seja, quanto mais seguro o sistema, mais difícil de implantar e mais overhead teremos na comunicação. Portanto, deve-se avaliar o quão importante são os dados que trafegam e são armazenados pela rede, quais os serviços que ela oferece ao mundo exterior (se estiver ligada à Internet), para definir se realmente é necessária a implantação de um esquema de autenticação e, caso positivo, qual o método mais adequado.












    [Page 6]

    Referencias



    [    RFC764] Telnet Protocol Specification

    [RFC959] File Transfer Protocol (FTP)

    [RFC1412] Telnet Authentication: SPX

    [RFC1411] Telnet Authentication: Kerberos Version 4

    [RFC1510] The Kerberos Network Authentication Service (V5)

    [RFC1416] Telnet Authentication Option

    [RFC1057] RPC: Remote Procedure Call - Protocol Specification Version 2

    [USENIX] Secure RPC Authentication (SRA) for Telnet and FTP
    David Safford, David Hess, and Douglas Lee Schales
    UNIX Security Symposium IV 1993
    USENIX Association



    [Page 7]

    © 1996 Hélder Garcia