RFC 3261 SIP: Session Initiation Protocol Junho 2002
incluídos na mensagem "externa". UA's que recebe qualquer um desses campos-cabeçalhos em um corpo criptografado DEVE ignorar os valores criptografados.
Note que extensões ao SIP podem definir campos-cabeçalhos adicionais; os autores dessas extensões devem descrever as propriedades de integridade e confidencialidade de tais campos-cabeçalhos. Se um UA do SIP encontrar um campo-cabeçalho desconhecido com uma violação de integridade, ele PRECISA ignorar o campo-cabeçalho.
23.4.2 Tunelando Integridade e Authenticação
Tunelar mensagens SIP dentro de corpos S/MIME podem fornecer integridade de campos-cabeçalhos SIP se os campos-cabeçalhos que o remetente deseja proteger são replicados em um corpo MIME "message/sip" assinado com uma assinatura CMS detached.
Desde que o corpo "message/sip" contém, ao menos, os identificadores de diálogo fundamentais (To, From, Call-ID, CSeq), então um corpo MIME assinado pode fornecer autenticação limitada. No mínimo, se o certificado usado para assinar o corpo for desconhecido ao receptor e não poder ser verificado, a assinatura pode ser usada para certificar que uma requisição posterior em um diálogo foi transmitida pelo mesmo titular do certificado que iniciou o diálogo. Se o receptor do corpo MIME assinado tem algum incentivo mais forte para confiar no certificado (porque eles foram capazes de validá-lo, eles o adquiriu um repositório confiável, ou eles o têm usado com freqüência), então, a assinatura pode ser tomado como uma assertiva forte da identidade do sujeito do certificado.
A fim de eliminar possíveis confusões sobre a adição ou subtração de campos-cabeçalhos inteiros, remetentes DEVEM replicar todos os campos-cabeçalhos da requisição dentro do corpo assinado. Quaisquer corpos de mensagem que exigem proteção para integridade PRECISAM ser anexados à mensagem "interna".
Se um cabeçalho Date estiver presente em uma mensagem com um corpo assinado, o receptor DEVE comparar o valor do campo-cabeçalho com seu próprio relógio interno, se aplicável. Se uma discrepância significativa de tempo for detectada (ao final de uma hora ou mais), o agente-usuário DEVE alertar o usuário sobre anomalia, e note que isso é uma violação potencial de segurança.
Se uma violação a integridade de uma mensagem for detectado por seu receptor, a mensagem PODE ser rejeitada com uma resposta 403 (Forbidden) se ela é uma requisição, ou qualquer diálogo existente PODE ser encerrado. UA's DEVEM notificar usuários dessa circunstância e requisitar orientação explícita de como proceder.
Rosenberg, et. al. Standards Track [Página 209]
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