Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


O UA então cria uma requisição REGISTER que DEVE ser endereçada com um Request-URI correspondente ao certificado do site recebeu do registrador. Quando o UA envia a requisição REGISTER sobre a conexão TLS existentes, o registrador DEVE desafiar a requisição com uma resposta 401 (Proxy Authentication Required). O parâmetro "realm" dentro do campo-cabeçalho Proxy-Authenticate da resposta DEVE corresponder ao domínio previamente dado pelo certificado do site. Quando o UAC recebe o desafio, ele DEVE solicitar ao usuário credenciais ou tomar uma credencial apropriada de um keyring correspondente ao parâmetro "realm" no desafio. O username dessa credencial DEVE corresponder à parte "userinfo" do URI no campo-cabeçalho To da requisição REGISTER. Uma vez que as credenciais Digest foram inseridas em um campo-cabeçalho Proxy-Autorização apropriado, o REGISTER deve ser resubmetido ao registrador.

Como o registrador exige do agente-usuário autenticar-se, seria difícil a um atacante forjar requisições REGISTER para o endereço de registro do usuário. Observe também que como o REGISTER é enviado através de uma conexão TLS confidencial, atacantes não seriam capazes de interceptar o REGISTER para armazenar credenciais por qualquer possível ataque de repetição.

Uma vez o registro tenha sido aceito pelo registrador, o UA DEVE deixar essa conexão TLS aberta desde que o registrador também atua como o servidor proxy para que requisições sejam enviadas aos usuários nesse domínio administrativo. A conexão TLS existente será reusada para entregar requisições entrantes ao UA, que acaba de realizar o registro.

Como o UA já foi autenticado ao servidor do outro lado da conexão TLS, todas as requisições que chegam por essa conexão são conhecidas por ter atravessado o servidor proxy – atacantes não podem criar requisições falsas que parecem ter atravessado esse servidor proxy.


26.3.2.2 Requisições Inter-Domínios

Agora vamos dizer que UA de Alice gostaria de iniciar uma sessão com um usuário em um domínio administrativo remoto, denominado "bob@biloxi.com". Vamos também dizer que o domínio administrativo local (atlanta.com) tem um proxy sainte local.

O servidor proxy que lida com requisições entrantes para um domínio administrativo também PODE atuar como um proxy sainte local; por questão de simplicidade vamos supor que esse seja o caso de atlanta.com (do contrário, o agente-usuário iniciaria uma nova conexão TLS para um servidor separado nesse momento). Supondo que o cliente tenha concluído o processo de registo 









Rosenberg, et. al.          Standards Track                   [Página 243]

Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:

User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.

Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de 
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:

MUST:
    PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, 
    NECESSITAR, É MANDATÓRIO.

MUST NOT:
    NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:
    DEVE, É RECOMENDADO.

SHOULD NOT:
    NÃO DEVE, NÃO É RECOMENDADO.

MAY:
    PODE, É OPCIONAL.