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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Note que está previsto que futuras extensões de segurança possam atualizar a força normativa associados ao S/MIME quando implementações S/MIME aparecerem e o espaço de problema se torne mais compreensível.


26.3.2 Soluções de Segurança

A operação desses mecanismos de segurança em conjunto pode seguir os modelos de segurança existentes de web e de e-mail em algum grau. Em um nível mais alto, UAs autenticar-se com servidores (servidores proxy, servidores redirect e registradores) com um username e senha Digest; servidores autenticar-se com UAs a um salto de distância, ou com outro servidor a um salto de distância (e vice-versa), com um certificado de site entregue pelo TLS.

Em um nível peer-to-peer, UA's confiam na rede para autenticarem-se entre si ordinariamente; contudo, S/MIME pode também ser usado para fornecer autenticação direta quando a rede não faz, ou se a própria rede não for confiável.

A seguir é um exemplo ilustrativo em que esses mecanismos de segurança são usados por vários UA's e servidores para evitar os tipos de ameaças descritas na Seção 26.1. Enquanto implementadores e administradores de rede PODEM seguir as orientações normativas dadas no restante dessa seção, essas são fornecidas apenas como implementações exemplo.


26.3.2.1 Registro

Quando um UA fica online e se registra em seu domínio administrativo local, ele DEVE estabelecer uma conexão TLS com seu registrador (a Seção 10 descreve como o UA alcança seu registrador). O registrador DEVE oferecer um certificado ao UA, e o site identificado pelo certificado PRECISA corresponder ao domínio em que o UA pretende registrar-se; por exemplo, se o UA pretende registrar o endereço de registro 'alice@atlanta.com', o certificado do site precisa identificar um host dentro do domínio atlanta.com (como sip.atlanta.com). Quando recebe a mensagem de certificado TLS, o UA DEVE verificar o certificado e inspecionar o site identificado pelo certificado. Se o certificado for inválido, revogado, ou se ele não identifica a parte apropriada, o UA NÃO PODE enviar a mensagem REGISTER e do contrário proceder ao registo.

Quando um certificado válido for fornecido pelo registrador, o UA sabe que o registrador não é um atacante que poderia redirecionar o UA, roubar senhas, ou tentar quaisquer ataques similares.








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

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.