RFC 3261 SIP: Session Initiation Protocol Junho 2002
Note que a segurança da sinalização SIP em si não tem nenhuma influência na segurança de protocolos usados juntos com o SIP, como RTP, ou com implicações de segurança de qualquer corpo do SIP específico pode transportar (embora segurança do MIME tem um papel importante na segurança do SIP). Qualquer mídia associada a uma sessão pode ser criptografada fim-de-fim, de forma independente de qualquer associado sinalização SIP. Criptografia de mídia está fora do escopo desse documento.
As considerações que seguem primeiro examina um conjunto de modelos clássicos de ameaças que, a grosso modo, identifica as necessidades de segurança do SIP. O conjunto de serviços de segurança exigidos para enfrentar essas ameaças é, então, detalhado, seguido por uma explicação de diversos mecanismos de segurança que podem ser usados ??para fornecer esses serviços. Em seguida, os requisitos para implementadores do SIP são enumerados, junto com implementações exemplares em que esses mecanismos de segurança poderia ser usados para melhorar a segurança do SIP. Algumas notas sobre privacidade concluir essa seção.
26.1 Modelos de Ataques e Ameaça
Essa seção detalha algumas ameaças que devem ser comuns à muitas implementações do SIP. Essas ameaças foram escolhidas especificamente para ilustrar cada um dos serviços de segurança que o SIP exige.
Os exemplos seguintes de modo nenhum fornecer uma lista exaustiva de ameaças contra o SIP; pelo contrário, essas são ameaças "clássicas" que demonstram a necessidade por serviços de segurança particulares que podem, potencialmente, evitar categorias inteiras de ameaças.
Esses ataques assume um ambiente no qual atacantes podem potencialmente ler qualquer pacote na rede – é previsível que o SIP será frequentemente usado na Internet pública. Atacantes na rede podem ser capazes de modificar pacotes (talvez em algum intermediário comprometido). Atacantes podem querer roubar serviços, espionar as comunicações ou interromper as sessões.
26.1.1 Seqüestro de Registro
O mecanismo de execução de registro no SIP permite que um agente-usuário se identifique a um registrador como um dispositivo no qual um usuário (designado por um endereço de registro) é localizado. Um registrador computa a identidade expressada no campo-cabeçalho From de uma mensagem REGISTER para determinar se essa requisição pode modificar os endereços de contato associada ao endereço de registro, no campo-cabeçalho To. Embora esses dois campos sejam freqüentemente os mesmos, existem muitas implementações válidas em que um terceiro pode registrar contatos em nome de um usuário.
Rosenberg, et. al. Standards Track [Página 233]
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