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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Essa política, contudo, só garante que a requisição veio do domínio que ele atribui a si; ele não permite biloxi.com averiguar como atlanta.com autenticou Alice. Somente se biloxi.com tiver alguma outra maneira de saber as políticas de autenticação de atlanta.com seria possível averiguar como Alice comprovou sua identidade. O biloxi.com poderia então instituir uma política ainda mais rigorosa que proibisse requisições que vêm de domínios que não são conhecidos administrativamente para partilhar uma política de autenticação comum com o biloxi.com.

Uma vez o INVITE foi aprovado pelo proxy biloxi, o servidor proxy DEVE identificar o canal TLS existente, se houver, associado ao usuário alvo dessa requisição (neste caso "bob@biloxi.com"). O INVITE deve ser proxy-iado por esse canal até Bob. Como a requisição é recebida por uma conexão TLS que anteriormente foi autenticada como sendo o proxy biloxi, Bob sabe que o campo-cabeçalho From não foi violado e que atlanta.com validou Alice, embora não necessariamente se deve ou não confiar identidade de Alice.

Antes de eles encaminharem a requisição, ambos os servidores proxy DEVEM adicionar um campo-cabeçalho Record-Route à requisição de sorte que todas as requisições futuras nesse diálogo passará por servidores proxy. Os servidores proxy podem, assim, continuar a prestar serviços de segurança pela vigência desse diálogo. Se os servidores proxy não adicionam-se ao Record Route, futuras mensagens passarão diretamente fim-de-fim entre Alice e Bob, sem quaisquer serviços de segurança (a menos que as duas partes concordam com alguma segurança fim-a-fim independente, como S/MIME). A esse respeito, o modelo trapezóide do SIP pode fornecer uma ótima estrutura, onde as convenções acordadas entre os proxy's do site podem fornecer um canal razoavelmente seguro entre Alice e Bob.

Um atacante espreitando essa arquitetura, por exemplo, seria incapaz de forjar uma requisição BYE e inseri-la no fluxo de sinalização entre Bob e Alice porque o atacante não tem como averiguar os parâmetros da sessão e também porque o mecanismo de integridade transitivamente protege o tráfego entre Alice e Bob.


26.3.2.3 Requisições de Peer-a-Peer

Alternativamente, considere um UA declarando a identidade "carol@chicago.com" que não tem proxy sainte local. Quando Carol deseja enviar um INVITE a "bob@biloxi.com", seu UA DEVE iniciar uma conexão TLS com o proxy biloxi diretamente (usando o mecanismo descrito em [4] para determinar a melhor forma de chegar o Request-URI dado). Quando seu UA recebe um certificado do proxy biloxi, esse DEVE ser verificado normalmente antes dela passa seu INVITE à conexão TLS. Entretanto, Carol não tem como provar 




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

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.