RFC 3261 SIP: Session Initiation Protocol Junho 2002
O uso do S/MIME no SIP está detalhado na Seção 23.
26.3 Implementando Mecanismos de Segurança
26.3.1 Exigências para Implementadores do SIP
Servidores proxy, servidores redirect e registradores PRECISAM implementar o TLS, e PRECISAM suportar ambas as autenticações mútua e mão única . É altamente RECOMENDADO que UA's sejam capazes de iniciar o TLS; UA's PODEM também ser capazes de agir como um servidor TLS. Servidores proxy, servidores redirect e registradores DEVEM possuir um certificado de site cujo assunto corresponda ao seu hostname canônico. UA's PODEM ter seus próprios certificados para autenticação mútua com o TLS, mas nenhuma provisão é dada nesse documento para uso deles. Todos os elementos SIP que suportam o TLS PRECISAM ter um mecanismo para validar certificados recebidos durante a negociação TLS; isso implica na posse de um ou mais certificados raiz emitidos por autoridades de certificação (preferencialmente distribuidores bem conhecidos de certificados de sites comparáveis àqueles que liberam certificados raiz para browsers web).
Todos os elementos SIP que suportam o TLS PRECISAM também suportar o esquema URI do SIPS.
Servidores proxy, servidores redirect, registradores e UA's PODEM também implementar o IPSec ou outros protocolos de segurança de camada inferior.
Quando um UA tenta contactar um servidor proxy, servidor redirect ou registrador, o UAC DEVE iniciar uma conexão TLS sobre a qual enviará mensagens SIP. Em algumas arquiteturas, UAS's PODEM receber requisições através de tais conexões TLS também.
Servidores proxy, servidores redirect, registrador e UA's PRECISAM implementar Autorização Digest, abrangendo todos os aspectos necessários em 22. Servidores proxy, servidores redirect e registradores DEVEM ser configurados com, ao menos, um realm Digest, e, ao menos, uma string "realm" suportada por um dado servidor DEVE corresponder ao hostname ou domainname do servidor.
UA's PODEM suportar a assinatura e criptografia de corpos MIME, e transferência de credenciais com S/MIME conforme descrito na Seção 23. Se um UA contém um ou mais certificados raiz de autoridades de certificação a fim de validar certificados para o TLS ou o IPSec, ele DEVE ser capaz de reusar esses para verificar certificados S/MIME, conforme o caso. Um UA PODE conter certificados raiz especificamente para validar certificados S/MIME.
Rosenberg, et. al. Standards Track [Página 241]
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