Esquema de Autenticação Digest no SIP :: Admirável Mundo Novo




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

quinta-feira, 13 de maio de 2010

Esquema de Autenticação Digest no SIP


Fonte: http://linuxnet.ch/groups/linuxnet/revisions/1727d/5



Autenticação no SIP

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.



Visão Geral da Autenticação Digest

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.

A autenticação Digest verifica isso se ambas as partes que se comunicam conhecem um segredo (secret) comum (uma senha).

Quando um servidor quer autenticar um usuário, ele gera desafio digest e o envia ao usuário. Um desafio digest típico se parece com isso:

Digest realm="iptel.org", qop="auth,auth-int",
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.

Agentes usuários SIP são supostos exibir o conteúdo do parâmetro ao usuário quando eles os perguntam pelo nome e senha de usuário de sorte que ele possa usar o nome e senha de usuário apropriados (desse servidor).

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.

Dessa forma, basicamente, nonce é uma espécie de identificador que garante que as credenciais digest recebidas foram realmente geradas por um desafio digest particular, e também limita a vida útil da resposta digest, evitando assim ataques de repetição futuros.

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.


Autenticação Digest e o SIP

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.

Quando um servidor SIP recebe uma requisição SIP e quer verificar a autenticidade do usuário antes de processar as requisições, ele examina se a requisição contém credenciais digest. Se não houver credenciais na requisição SIP, ele vai gerar uma resposta negativa final e incluir o desafio digest na resposta.

Quando um cliente recebe a resposta (contendo o desafio digest), é suposto que ele vai calcular uma resposta digest adequada e envia novamente a requisição, dessa vez incluindo as credenciais digest que foram calculadas.

O servidor então verifica a resposta digest e processa a requisição quando a verificação for bem sucedida.

Os servidores proxy usam a resposta "407 Proxy Authentication Required" e incluem o desafio digest no campo do cabeçalho "Proxy-Authenticate". Um exemplo de tal desafio pode ter essa aparência:

SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 195.37.78.121:5060
From: sip:jan@iptel.org;tag=3944790419
To: sip:5060@iptel.org;user=phone>;tag=794fe65c16edfdf45da4fc39a5d2867
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="iptel.org", nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2"
Content-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 Unauthorized
Via: SIP/2.0/UDP 218.79.100.193:65030;branch=z9hG4bK1ce21dab
To: "IPTel844978" sip:844978@iptel.org>;tag=794fe65c16edfdf45da4fc39
From: "IPTel844978" sip:844978@iptel.org>;tag=1fd6218e
CSeq: 88608141 REGISTER
WWW-Authenticate: Digest realm="iptel.org", nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2"
Content-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.

Quando incluindo a resposta digest os clientes adicionam o campo cabeçalho "Authorization" ou "Proxy-Authorization" que contém a resposta digest. O exemplo seguinte mostra uma mensagem REGISTER que contém credenciais digest.


REGISTER sip:iptel.org SIP/2.0
Via: SIP/2.0/UDP 195.37.78.121:5060
CSeq: 102 REGISTER
User-Agent: CSCO/4
Authorization: Digest username="jan",realm="iptel.org", uri="sip:iptel.org",response="dab81127b9a7169ed57aa4a6ca146184",
nonce="3f9fc0f9619dd1a712b27723398303ea436e839a",algorithm=md5
Content-Length: 0
Expires: 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.

Quando um agente usuário SIP recebe um desafio digest, é suposto re-enviar a mesma requisição de novo, mas dessa vez com as credenciais digest apropriadas. Isso também significa que o agente usuário precisa incrementar o número CSeq na requisição a fim de evitar tratar a nova requisição como uma retransmissão pelo servidor.

Como desafiar uma requisição significa que a requisição será enviado novamente com CSeq superior, não é possível desafiar requisições ACK e CANCEL. Ambas as requisições precisam ter o mesmo CSeq que da requisição inicial e, portanto, não podem ser desafiadas.

Todas as outras requisições podem ser desafiadas, embora de tempos em tempos surjam implementações que parecem ter problemas com o desafiar requisições SIP não muito comuns.

Há dois casos em que são implementados frequentemente e merece uma descrição mais detalha: autenticação de mensagens REGISTER e autenticação de mensagens INVITE. Nós vamos descrevê-las em partes separadas.




Autenticação de Registro

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.

Se um servidor não autenticar requisições REGISTER então qualquer um pode registrar qualquer contato para algum usuário, assim seqüestrando chamadas dessa pessoa. Autenticação é obviamente muito importante para proteger contra isso e, portanto, a autenticação de mensagens REGISTER deve estar sempre habilitado.



height=303




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".

Requisições provenientes de usuários estrangeiros não podem ser desafiados, porque os usuários estrangeiros geralmente não possuem um nome e senha (username e password) de usuário registrados nesse servidor. Exigência de autenticação tornará impossível chamadas entrantes de usuários estrangeiros.



height=321




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:




Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.