Fonte: http://linuxnet.ch/groups/linuxnet/revisions/1727d/5
Nessa seção nós vamos descrever os mecanismos de autenticação utilizados em redes baseada no SIP. Primeiro vamos descrever os conceitos básicos da autenticação Digest, porquanto nas próximas seções vamos dar uma breve visão geral de como a Autenticação Digest se aplica às mensagens SIP, quando ela deve ser ou não usada.
A Autenticação Digest é um mecanismo de autenticação simples desenvolvido originalmente para o protocolo HTTP (que é frequentemente chamado de HTTP digest) que está descrito na RFC2671. O mecanismo de autenticação é muito simples. É baseado em hashes criptográficas para evitar a transferência de senha do usuário em texto claro.
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5
Ele consiste de um conjunto de parâmetros que são enviados ao usuário. O usuário então usa esses parâmetros para gerar a resposta digest adequada e a devolve ao servidor. O significado dos parâmetros no desafio digest é o seguinte:
realm: O parâmetro realm é obrigatório e precisa estar presente em todos os desafios.
Seu objetivo é identificar credenciais dentro de uma mensagem SIP. No caso do SIP, ele é normalmente definido igual ao domínio do servidor proxy no qual é responsável.
nonce: é uma string de dados especificada pelo servidor que é gerada exclusivamente toda vez que um servidor lança um desafio digest. O parâmetro nonce é construído geralmente igual ao hash MD5 a partir de alguns dados. Os dados geralmente inclui carimbo de tempo e uma frase secreta do servidor gerador. Isso garante que cada tag nonce tenha vida útil limitada (ou seja, expira depois de algum tempo e não pode ser mais usada depois) e também é única (isto é, nenhum outro servidor será capaz de gerar o mesmo nonce).
Os clientes usam o parâmetro nonce para gerar uma resposta digest e, portanto, o servidor receberá de volta o conteúdo nonce em uma resposta digest. Ele geralmente verifica a validade da tag nonce antes que ele possa verificar o resto da resposta digest.
opaque: é uma string de dados opaco passado ao usuário em um desafio. O usuário passará de volta a string de dados ao servidor em uma resposta digest. Isso permite que servidores não mantenham estado. Se houver algum estado que necessita ser mantido entre o desafio e a resposta, eles podem passá-lo ao cliente usando esse parâmetro e o lê novamente depois, quando uma resposta digest chegar.
algorithm: algoritmo usado para calcular hashes. Atualmente só o MD5 é suportado.
qop: A qualidade da proteção. O parâmetro especifica quais os esquemas de proteção o servidor pode suportar. Um cliente vai escolher um da lista. O valor auth "indica apenas autenticação", já o valor auth-int "indica autenticação com alguma proteção de integridade". Para uma descrição mais detalhada, consulte RFC2617.
Após receber o desafio digest, um agente usuário perguntará ao usuário pelo username e senha (se não estiver pré-configurado), gera uma resposta digest e enviar a resposta ao servidor. A resposta digest pode ter essa aparência:
Digest username="jan", realm="iptel.org", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:iptel.org", qop=auth, nc=00000001, cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", opaque=""
Como podemos ver, a resposta digest é similar ao desafio digest. Aqueles parâmetros que são iguais possuem o mesmo significado de antes quando do desafio digest. Nós vamos descrever apenas os novos parâmetros brevemente:
uri - O parâmetro contém a URI que os clientes desejam acessar.
qop - O nível de proteção escolhida pelo cliente.
nc - Contagem de nonce, o valor é o número de contagem hexadecimal do número de requisições (incluindo a requisição atual) que o cliente tem enviado com o valor nonce nessa requisição. Por exemplo, na primeira requisição enviada em resposta a um determinado valor nonce, o cliente envia "nc=00000001". O objetivo dessa diretiva é permitir ao servidor detectar repetições de requisições, mantendo sua própria cópia dessa contagem - se o mesmo valor for visto duas vezes, então a requisição é uma repetição.
cnonce - O valor é um valor string opaco marcada fornecida pelo cliente e usado tanto pelo cliente quanto pelo servidor para evitar ataques devido a escolha de texto plano, para fornecer autenticação mútua, e fornecer alguma proteção de integridade da mensagem.
response - Uma string computada pelo agente usuário que tenta provar que o usuário conhece uma senha.
Quando da recepção de uma resposta digest, o servidor recalcula o valor do parâmetro response para fins de comparação, usando os atributos fornecidos pelo cliente e a senha armazenada no servidor. Se o resultado for idêntico a resposta recebida do cliente, então, o cliente provou conhecer a senha e ele é autenticado.
Nós temos descrito em como o desafio e a resposta digest se parecem, mas ainda não descrevemos como são usados em mensagens SIP. Como o mecanismo de autenticação foi originalmente desenvolvido para o protocolo HTTP e como o SIP é muito semelhante a esse protocolo, mapear desafio e resposta digest para as mensagens SIP é tarefa fácil e simples. Ela é descrita na RFC3261.
SIP/2.0 407 Proxy Authentication RequiredVia: SIP/2.0/UDP 195.37.78.121:5060Call-ID: 3541699089@195.37.78.121CSeq: 1 INVITEContent-Length: 0
Agentes usuários SIP (incluindo registradores e agentes usuários back-to-back) usam a resposta "401 Unauthorized" para o desafio digest. Um exemplo de tal desafio poderia ser:
SIP/2.0 401 UnauthorizedVia: SIP/2.0/UDP 218.79.100.193:65030;branch=z9hG4bK1ce21dabCSeq: 88608141 REGISTERContent-Length: 0
Respostas 407 são usadas pelos elementos SIP (principalmente servidores SIP proxy), que não sejam o destino final para a requisição e após a autenticação irá encaminhar outras requisições. Respostas 401 são usadas pelos elementos SIP que sejam o destino final para a requisição e após a autenticação irá gerar uma resposta final.
Via: SIP/2.0/UDP 195.37.78.121:5060From: sip:jan@iptel.orgCSeq: 102 REGISTERUser-Agent: CSCO/4Authorization: Digest username="jan",realm="iptel.org", uri="sip:iptel.org",response="dab81127b9a7169ed57aa4a6ca146184",nonce="3f9fc0f9619dd1a712b27723398303ea436e839a",algorithm=md5Content-Length: 0Expires: 10
Cenários Básicos
Nós descrevemos em como autenticação digest se parece e como desafios e respostas digest são aplicadas em mensagens SIP. Nesse capítulo, nós vamos estudar quais mensagens SIP podem ou não ser desafiadas. Nós iremos descrever também duas situações mais comuns em que a Autenticação Digest é usada.
Autenticação de mensagens REGISTER é muito importante e precisa ser feita por cada servidor SIP proxy. Com mensagens REGISTER SIP, agentes usuários estão informando ao servidor de sua localização atual de sorte que o servidor sabe onde enviar as demais requisições.
Autenticação de Invite
Autenticação de requisições INVITE realmente não é necessária, mas é uma boa prática fazê-lo. Um servidor SIP proxy pode apenas desafiar requisições que são provenientes de usuários que pertencem a um domínio administrativo pelo qual o servidor proxy é responsável. Isso significa que um proxy responsável, por exemplo, pelo domínio iptel.org só pode desafiar requisições que tenha iptel.org no campo cabeçalho "From".
Script Perl de Register SIP
O script seguinte pode ser usado para resolução de problema. Ele fará um registro SIP em algum Servidor SIP Proxy:
sh: highlight: command not found
Você precisará especificar uma linguagem como essa:
Linguagens suportadas pela sintaxe em realce:
(error loading support language list)
Nenhum comentário:
Postar um comentário