RFC 3261 SIP: Session Initiation Protocol Junho 2002
23.4 Privacidade e Integridade do Cabeçalho SIP usando S/MIME:
Tunelamento SIP
Como meio de fornecer algum grau autenticação, confidencialidade ou integridade fim-a-fim
aos campos-cabeçalhos do SIP, S/MIME podem encapsular mensagem SIP inteira dentro de corpos
MIME do tipo "message/sip" e então, aplicar segurança MIME a esses corpos da mesma forma
que corpos típicos do SIP. Essas requisições e respostas do SIP encapsuladas não constituem
um diálogo ou transação separada, elas são cópia da mensagem "externa" que é usada para
verificar a integridade ou a fornecer informações adicionais.
Se um UAS receber uma requisição que contém um corpo S/MIME "message/sip" tunelado, ele
DEVE incluir um corpo "message/sip" tunelado na resposta com o mesmo smime-type. Quaisquer
corpos MIME tradicionais (como SDP) DEVEM ser anexado à mensagem "interna" de modo que
possam também se beneficiar da segurança S/MIME. Note que corpos "message/sip" podem ser
enviados como parte de um corpo MIME "multipart/mixed" se quaisquer tipos MIME não seguros
devem ser também transmitidos em uma requisição.
23.4.1 Propriedades Integridade e Confidencialidade de Cabeçalhos do SIP
Quando os mecanismos S/MIME de integridade ou confidencialidade são usados, pode haver
discrepâncias entre os valores na mensagem "interna" e os valores na mensagem "externa".
As regras para manipular tais diferenças para todos os campos-cabeçalhos descritos nesse
documento são fornecidas nessa seção. Note que para efeitos de fazer timestamp solto,
todas as mensagens SIP que tunela "message/sip" DEVEM conter um cabeçalho Date nos
cabeçalhos tanto "interno" quanto "externo".
23.4.1.1 Integridade
Sempre que verificações são executadas, a integridade de um campo-cabeçalho deve ser
determinada batendo o valor do campo-cabeçalho no corpo assinado com aquele nas mensagens
"externas" usando as regras de comparação do SIP, como descrito em 20.
Campos-cabeçalhos que podem ser legitimamente modificados por servidores proxy são:
Request-URI, Via, Record-Route, Route, Max-Forwards e Proxy-Authorization. Se esses
campos-cabeçalhos não ficarem intactos fim-a-fim, implementações NÃO DEVEM considerar
isso uma violação de segurança. Mudanças em quaisquer outros campos-cabeçalhos definidos
nesse documento constituem uma violação de integridade; usuários PRECISAM ser notificados
de alguma discrepância.
Rosenberg, et. al. Standards Track [Página 207]
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