RFC 3261 SIP: Session Initiation Protocol Junho 2002
O TLS fornece segurança na camada de transporte sobre protocolos orientados à conexão (para os propositos desse documento, o TCP); "tls" (significa TLS sobre o TCP) pode ser especificado como o protocolo de transporte desejado dentro de um valor de campo-cabeçalho Via ou SIP-URI. O TLS é mais adequado a arquiteturas em que segurança nó-a-no for necessária entre hosts sem nenhuma associação confiável pré-existente. Por exemplo, Alice confia em seu servidor proxy local, que após a troca de certificado decide confiar no servidor proxy local de Bob, que Bob confia, portanto, Bob e Alice podem se comunicar de forma segura.
O TLS precisa ser fortemente acoplado a uma aplicação SIP. Note que mecanismos de transporte são especificados em uma base nó-a-nó no SIP, assim um UA que envia requisições sobre TLS a um servidor proxy não tem nenhuma garantia de que o TLS será usado fim-a-fim.
A ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA [6] PRECISA ser suportada at a minimum por implementadores quando o TLS é usada em uma aplicação SIP. Para propósitos de retro-compatibilidade, servidores proxy, servidores redirect, e registradores DEVEM suportar a TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementadores PODEM também suportar qualquer outra ciphersuite.
26.2.2 Esquema URI do SIPS
O esquema URI do SIPS adere à sintaxe do URI do SIP (descrito em 19), embora o esquema string seja "sips" ao invés de "sip". Contudo, a semântica do SIPS é muito diferente da semântica de URI do SIP. O SIPS permite que recursos a especificar que eles devam ser alcançados de forma segura.
Um URI SIPS pode ser usado como um endereço de registro para um usuário particular - o URI pelo qual o usuário é canonicamente conhecido (em seus cartões de visita, no campo-cabeçalho de suas requisições, no campo-cabeçalho To de requisições REGISTER). Quando usado como Request-URI de uma requisição, o esquema SIPS significa que cada nó no qual a requisição é encaminhada, até a requisição chega a entidade SIP responsável pela parte domínio do Request-URI, precisa ser protegido com o TLS; uma vez ela alcance o domínio em questão, ela é tratada de acordo com a política segurança local e de roteamento, possivelmente usando o TLS inteiramente para qualquer nó último a um UAS. Quando usado pelo originador de uma requisição (como seria o caso se eles empregassem um URI do SIPS como o endereço de registro do alvo), o SIPS dita que o caminho inteiro da requisição ao domínio alvo seja assim protegido.
O esquema SIPS é aplicável de muitas maneiras diferentes em que URI's do SIP são usados ??no SIP atualmente em adição ao Request-URI, que inclui em endereços-de-registro, os endereços de contato (o conteúdo de cabeçalhos Contact, incluindo aqueles de métodos REGISTER) e cabeçalhos Route. Em cada instância, o esquema URI do SIPS permite a esses campos existentes
Rosenberg, et. al. Standards Track [Página 239]
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