RFC 3261 SIP: Session Initiation Protocol Junho 2002
causas para cautela, mas não necessariamente indicações de que um ataque está em andamento. Usuários podem abortar qualquer tentativa de conexão ou recusar uma requisição de conexão eles têm recebido; em linguagem de telefonia, eles podem desligar e ligar de volta. Usuários podem desejar encontrar um meio alternativo para contactar a outra parte e confirmar que sua chave tem legitimamente alterado. Note que os usuários são por vezes obrigados a mudar seus certificados, por exemplo, quando eles suspeitam que o sigilo de sua chave privada foi comprometido. Quando sua chave privada não mais é privada, usuários precisam legitimamente gerar uma nova chave e re-estabelecer a confiança com quaisquer usuários que mantinham sua chave antiga.
Finalmente, se durante o curso de um diálogo um UA recebe um certificado em uma mensagem SignedData CMS que não corresponde com os certificados anteriormente trocados durante um diálogo, o UA PRECISA notificar seu usuário da mudança, de preferência em termos que indicam que isso é um potencial violação de segurança.
23.3 Protegendo corpos MIME
Existem dois tipos de corpos MIME seguros que são de interesse ao SIP: uso desses corpos deve seguir a especificação S/MIME [24], com poucas variações.
o "multipart/signed" PRECISA ser usado só com assinaturas CMS detached.
Isso permite retro-compatibilidade com receptores compatíveis não-S/MIME.
o Corpos S/MIME DEVEM ter um campo-cabeçalho Content-Disposition, e o valor do parâmetro "handling" DEVE ser "required".
o Se um UAC não tem certificado em seu keyring associado ao endereço de registro para o qual ele deseja enviar uma requisição, ele não pode enviar uma mensagem MIME "application/pkcs7-mime" criptografada. UAC's PODEM enviar uma requisição inicial, tal como uma mensagem OPTIONS com uma assinatura CMS detached, a fim de solicitar o certificado do lado remoto (a assinatura DEVE ser sobre um corpo "message/sip" do tipo descrito na Seção 23.4).
Note que futura padronização que funciona no S/MIME pode definir chaves baseadas em não-certificados.
o Remetentes de corpos S/MIME DEVEM usar o atributo "SMIMECapabilities" (ver Seção 2.5.2 de [24]) para expressar suas capacidades e preferências em comunicações adicionais. Note especialmente que remetentes PODEM usar a capacidade "preferSignedData"
Rosenberg, et. al. Standards Track [Página 205]
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