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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


do qual o usuário é um cliente (que é um cenário bastante comum e, portanto, o Digest fornece uma função extremamente útil). Em contraste, o escopo do TLS é interdomínios ou multirealm, já que certificados são frequentemente verificáveis globalmente, de sorte que o UA pode autenticar o servidor sem nenhuma associação pré-existente.


26.4.2 S/MIME

O defeito mais proeminente com o mecanismo S/MIME é a ausência de uma infra-estrutura de chave pública preponderante para os usuários finais. Se certificados auto-assinados (ou certificados que não podem ser verificados por um dos participantes em um diálogo) são usados??, o mecanismo de troca de chaves baseado no SIP descritos na Seção 23.2 é suscetível a um ataque man-in-the-middle com o qual o atacante pode, potencialmente, inspecionar e modificar corpos S/MIME. O atacante precisa interceptar a primeira troca de chaves entre as duas partes de um diálogo, remover assinaturas CMS detached existentes da requisição e resposta, e inserir uma assinatura CMS detached diferentes contendo um certificado fornecido pelo atacante (mas que parece a ser um certificado para o endereço-de-registro adequado). Cada parte pensará que têm trocado chaves com o outro, quando na verdade cada um tem a chave pública do atacante.

É importante notar que o atacante só pode potencializar essa vulnerabilidade na primeira troca de chaves entre duas partes - em ocasiões subsequentes, a alteração da chave seria perceptível aos UA's. Também seria difícil ao atacante permanecer no caminho de todos os diálogos futuros entre as duas partes ao longo do tempo (porquanto dias, semanas ou passar anos potencialmente).

O SSH é suscetível ao mesmo ataque man-in-the-middle na primeira troca de chaves; contudo, é amplamente reconhecido que, ao mesmo tempo que o SSH não é perfeito, ele melhora a segurança de conexões. O uso de impressões digitais de chave poderia fornecer alguma assistência ao SIP, assim como ela presta ao SSH. Por exemplo, se duas partes usam o SIP para estabelecer uma sessão de comunicação de voz, cada uma poderia ler a impressão digital da chave que eles receberam do outro, o que poderia ser comparada com a original. Por certo seria mais difícil ao man-in-the-middle emular as vozes dos participantes do que sua sinalização (uma prática que foi usada com o telefone seguro Clipper baseado em chip).

O mecanismo S/MIME permite aos UA's enviarem requisições criptografadas sem preâmbulo, se elas possuirem um certificado para o endereço-de-registro destino em seu keyring. Entretanto, é possível que qualquer dispositivo particular registrado com um endereço-de-registro não terá o certificado que foi previamente empregado pelo usuário atual do dispositivo, e que, portanto, será incapaz de processar uma 


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

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.