RFC 3261 SIP: Session Initiation Protocol Junho 2002
designar recursos seguros. A maneira pela qual um URI do SIPS é de-referenciado em qualquer um desses contextos tem suas próprias propriedades de segurança as quais estão detalhadas em [4].
O uso do SIPS em particular implica que a autenticação TLS mútua DEVE ser empregada, como DEVE a ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Certificados recebidos no processo de autenticação DEVEM ser validados com certificados raiz mantidos pelo cliente; falha ao validar um certificado DEVE resultar na falha da requisição.
Note que no esquema URI do SIPS, o transporte é independente do TLS, e portanto "sips:alice@atlanta.com;transport=tcp" e "sips:alice@atlanta.com;transport=sctp" são ambos válidos (embora observe que o UDP não é um transporte válido ao SIPS). O uso de "transport=tls" tem sido consequentemente descontinuado, parciamente porque ele era específico a um único nó da requisição. Essa é uma mudança desde a RFC 2543.
Usuários que distribuem um URI do SIPS como um endereço-de-registro pode eleger operar dispositivos que recusar requisições em transportes inseguros.
26.2.3 Autenticação HTTP
O SIP oferece uma capacidade de desafio, baseado na autenticação HTTP, que depende dos códigos respostas 401 e 407, bem como dos campos-cabeçalhos para transportar desafios e credenciais. Sem modificações significativas, o reuso do esquema de autenticação HTTP Digest no SIP permite a proteção replay e autenticação mão-única.
O uso da autenticação Digest no SIP está detalhada na Seção 22.
26.2.4 S/MIME
Como discutido acima, criptografar todas as mensagens SIP fim-de-fim com o propósito de confidencialidade não é apropriado porque intermediários de rede (como servidores proxy) precisam ver certos campos-cabeçalhos, a fim de rotear mensagens corretamente, e se esses intermediários forem excluídos das associações de segurança, então as mensagens SIP não serão essencialmente roteáveis.
No entanto, o S/MIME permite aos UA's do SIP criptografar corpos MIME dentro do SIP, protegendo esses corpos fim-a-fim sem afetar os cabeçalhos das mensagens. O S/MIME pode fornecer confidencialidade e integridade fim-a-fim de corpos de mensagens, bem como autenticação mútua. Também é possível usar o S/MIME para fornecer uma forma de integridade e confidencialidade para campos-cabeçalhos SIP através de tunelamento de mensagem do SIP.
Rosenberg, et. al. Standards Track [Página 240]
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