RFC 3261 SIP: Session Initiation Protocol Junho 2002
requisição criptografada corretamente, o que poderia levar a algum erro evitável de sinalização. Isto é especialmente provável quando uma requisição criptografada é bifurcada.
As chaves associadas com o S/MIME são mais úteis quando associadas a um usuário particular (um endereço-de-registro), em vez de um dispositivo (um UA). Quando usuários se movem de dispositivos, pode ser difícil transportar chaves privadas de forma segura entre UA's; como tais chaves poderão ser adquiridas por um dispositivo está fora do escopo desse documento.
Outra dificuldade mais prosaica com o mecanismo S/MIME é que ele pode resultar em mensagens muito grandes, especialmente quando o mecanismo de tunelamento do SIP descrito na Seção 23.4 for usado. Por essa razão, É RECOMENDADO que o TCP deve ser usado como um protocolo de transporte quando o tunelamento S/MIME for empregado.
26.4.3 TLS
A preocupação mais comumente manifestada sobre o TLS é que ele não pode rodar sobre o UDP; o TLS exige um protocolo de transporte subjacente orientado à conexão, que, para os propositos desse documento significa o TCP.
Também pode ser árduo a um servidor proxy local sainte e/ou registrador manter muitas conexões TLS longas simultâneas com muitos UAs. Isso introduz algumas preocupações válidas sobre escalabilidade, especialmente para ciphersuites intensivo. Manter a redundância de conexões TLS longas, especialmente quando um UA é o único responsável para seu estabelecimento, também poderia ser complicado.
O TLS só permite a entidades SIP autenticar servidores aos quais elas são adjacentes; o TLS oferece segurança nó-a-nó estritamente. Nem o TLS, e nem qualquer outro mecanismo especificado nesse documento, permite aos clientes autenticarem servidores proxy para quem eles não podem formar uma conexão TCP direta.
26.4.4 URI's do SIPS
Realmente usar o TLS em cada segmento de um caminho de requisição implica que o UAS que encerra precisa ser acessível sobre o TLS (talvez registrando com um URI do SIPS como um endereço de contacto). Esse é o uso preferencial do SIPS. Muitas arquiteturas válidas, contudo, usa o TLS com a parte segura do caminho da requisição, mas dependem de algum outro mecanismo para o nó final com um UAS, por exemplo. Portanto, o SIPS não pode garantir que o uso do TLS será fim-a-fim verdadeiramente. Note que como muitos UA's não aceitam conexões TLS entrantes, mesmo aqueles UA's que suportam o TLS podem ser exigidos manter conexões TLS persistentes, conforme descrito na seção limitações do TLS acima, a fim de receber requisições no TLS como um UAS.
Rosenberg, et. al. Standards Track [Página 249]
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