RFC 3261 SIP: Session Initiation Protocol Junho 2002
26.1.3 Adulteração de Corpos de Mensagem
Normalmente, UA's do SIP roteiam requisições através de servidores proxy confiáveis. Independentemente da forma como essa confiança é estabelecida (autenticação de proxy's é discutida em outra parte dessa seção), um UA pode confiar em um servidor proxy para rotear uma requisição, mas não para inspecionar ou possivelmente modificar os corpos contidos nessa requisição.
Considere um UA que está usando corpos de mensagens SIP para comunicar chaves de criptografia da sessão para uma sessão de mídia. Embora ele confie no servidor proxy do domínio que está contactando para entregar a sinalização corretamente, ele pode não querer os administradores de domínio serem capazes de decifrar qualquer sessão de mídia subseqüentes. Pior ainda, se o servidor proxy era malicioso ativamente, poderia modificar a chave de sessão, seja atuando como um man-in-the-middle, ou talvez mudando as características de segurança requisitadas pelo UA originador.
Essa família de ameaças se aplica não só às chaves de sessão, mas às muitas formas concebíveis de conteúdo transportado fim-de-fim no SIP. Essas podem incluir corpos MIME que devem ser entregues ao usuário, o SDP, ou sinais de telefonia encapsulados, entre outros. Atacantes podem tentar modificar corpos SDP, por exemplo, a fim de apontar fluxos de mídia RTP para um dispositivo de escuta telefônica, a fim de espionar as comunicações de voz subseqüentes.
Note também que alguns campos-cabeçalhos no SIP são significantes fim-a-fim, por exemplo, o Subject. UA's podem ser protetores desses campos-cabeçalhos, bem como dos corpos (um intermediário malicioso que muda o campo-cabeçalho Subject pode fazer uma requisição importante parece ser spam, por exemplo). Contudo, como muitos campos-cabeçalhos são legitimamente inspecionados ou alterados por servidores proxy como uma requisição será roteada, nem todos os campos-cabeçalhos devem ser protegidos fim-a-fim.
Por essas razões, o UA pode querer proteger corpos de mensagens SIP, e, em alguns casos limitados campos-cabeçalhos, fim-a-fim. Os serviços de segurança exigidos para corpos incluem confidencialidade, integridade e autenticação. Esses serviços fim-a-fim devem ser independentes dos meios usados para proteger interações com intermediários, como servidores proxy.
26.1.4 Derrubando Sessões
Uma vez que um diálogo foi estabelecido através da troca de mensagens iniciais, requisições subseqüentes podem ser enviadas as quis modificam o estado do diálogo e/ou sessão. É crítico que principais em uma sessão possam ter certeza de que tais requisições não são forjadas por atacantes.
Rosenberg, et. al. Standards Track [Página 235]
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.
Nenhum comentário:
Postar um comentário