RFC 3261 SIP: Session Initiation Protocol Junho 2002
criptografem as requisições ou respostas SIP inteiras no circuito numa base nó-a-nó, e que permitam aos endpoints verificarem a identidade de servidores proxy a quem eles enviam requisições.
Entidades SIP também têm a necessidade de identificar-se entre si de uma forma segura. Quando um endpoint SIP certifica a identidade de seu usuário com um UA peer ou com um servidor proxy, tal identidade deve ser de alguma forma verificável. Um mecanismo de autenticação criptográfica é fornecido no SIP para atender a esse requisito.
Um mecanismo de segurança independente para corpos de mensagens do SIP fornece uma forma alternativa de autenticação mútua fim-a-fim, bem como fornece um limite para até que nível agentes-usuários precisam de intermediários confiáveis.
26.2.1 Segurança nas Camadas Rede e Transporte
A segurança nas camadas de transporte ou de rede criptografa o tráfego de sinalização, garantindo a confidencialidade e integridade da mensagem.
Muitas vezes, certificados são usados no estabelecimento de segurança na camada mais baixa e esses certificados também podem ser usados ??para fornecer uma forma de autenticação em muitas arquiteturas.
Duas alternativas populares para fornecer segurança na camada de transporte e de rede são, respectivamente, o TLS [25] e o IPSec [26].
O IPSec é um conjunto de ferramentas de protocolo no nível da camada de rede que, coletivamente, pode ser usado como um substituto seguro ao tradicional IP (Internet Protocol). O IPSec é mais comumente usado em arquiteturas em que um conjunto de hosts ou de domínios administrativos têm uma relação de confiança existente entre si. O IPSec é normalmente implementado no nível do sistema operacional em um host, ou em um gateway de segurança que fornece confidencialidade e integridade para todo tráfego que ele recebe de uma interface específica (como em uma arquitetura VPN). O IPSec também pode ser usado em uma base nó-a-nó.
Em muitas arquiteturas o IPSec não exige a integração com aplicações SIP; o IPSec é talvez o mais adequado a implementar onde adicionar segurança diretamente aos hosts SIP seria árduo. UA's que têm um relacionamento de esquema pré-compartilhado de chave com seu servidor proxy de primeiro-nó também são bons candidatos a usar o IPSec. Qualquer instalação de IPSec com o SIP exigiria um perfil IPSec que descreva as ferramentas de protocolo que seriam necessárias para proteger o SIP. Nenhum perfil é fornecido nesse documento.
Rosenberg, et. al. Standards Track [Página 238]
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