RFC 3261 SIP: Session Initiation Protocol Junho 2002
Serviços de localização não são obrigados a fornecer um binding SIPS para um Request-URI do SIPS. Embora serviços de localização sejam comumente povoados por registros de usuário (conforme descrito na Seção 10.2.1), vários outros protocolos e interfaces poderiam concebivelmente fornecer endereços de contato para um AOR, e essas ferramentas são gratuitas para mapear URI's do SIPS para URI's do SIP conforme apropriado. Quando consultado bindings, um serviço de localização retorna seus endereços de contato sem importar se ele recebeu uma requisição com um Request-URI do SIPS. Se um servidor redirect estiver acessando o serviço de localização, cabe à entidade processar o campo-cabeçalho Contact de um redirecionamento para determinar a propriedade dos endereços de contato.
Assegurar que o TLS será usado em todos os segmentos da requisição até o domínio alvo é um tanto complexo. É possível que servidores proxy autenticados criptograficamente ao longo do caminho que não são compatíveis ou comprometidos podem escolher descartar as regras de encaminhamento associados com o SIPS (e as regras de encaminhamento geral na Seção 16.6). Tais intermediários maliciosos poderiam, por exemplo, mudar o alvo de uma requisição de um URI do SIPS para um URI do SIP em uma tentativa de rebaixar a segurança.
Alternativamente, um intermediário pode legitimamente mudar o alvo de uma requisição de um URI do SIP para um URI do SIPS. Destinatários de uma requisição cujo Request-URI usa o esquema URI do SIPS, portanto não pode supor com base no Request-URI apenas que o SIPS foi usado para o caminho da requisição inteira (a partir do cliente em diante).
Para tratar essas preocupações, é RECOMENDADO que destinatários de uma requisição cujo Request-URI contém um URI do SIP ou do SIPS inspecionem o valor do campo-cabeçalho To pra ver se ele contém um URI do SIPS (embora note que não constitui uma violação de segurança se esse URI tiver o mesmo esquema, mas não é equivalente ao URI no campo-cabeçalho To). Embora clientes possam escolher preencher o Request-URI e o campo-cabeçalho To de uma requisição de forma diferente quando o SIPS for usado, essa disparidade pode ser interpretada como uma possível violação de segurança, e a requisição possa ser consequentemente rejeitada por seu destinatário. Destinatários PODEM também inspecionar o chain do cabeçalho Via, a fim de verificar duplamente se o TLS foi ou não usado no caminho inteiro da requisição até o domínio administrativo local ser atingido. O S/MIME pode também ser usado pelo UAC originador para ajudar assegurar que a forma original do campo-cabeçalho To é transportado fim-a-fim.
Se o UAS tem razões para acreditar que o esquema do Request-URI foi indevidamente modificado em trânsito, o UA DEVE notificar seu usuário de uma potencial violação de segurança.
Rosenberg, et. al. Standards Track [Página 250]
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