Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Sob um esquema de autenticação que usa respostas para transportar valores usados para computar nonces (como Digest), alguns problemas surgem para quaisquer requisições que não têm resposta, incluindo o ACK. Por essa razão, quaisquer credenciais no INVITE que foram aceitas por um servidor PRECISAM ser aceitas por esse servidor para o ACK. UAC's que criam uma mensagem ACK duplicará todos os valores dos campos-cabeçalhos Authorization e Proxy-Authorization que apareceram no INVITE a qual o ACK corresponde. Servidores NÃO PODE tentar desafiar um ACK.

Embora o método CANCEL tenha uma resposta (uma 2xx), servidores NÃO PODEM tentar desafiar requisições CANCEL porque essas requisições não podem ser reenviadas. Geralmente, uma requisição CANCEL DEVE ser aceita por um servidor se ela vem do mesmo salto que enviou a requisição a ser cancelada (contanto que algum tipo de associação de segurança da camada de transporte ou de rede, conforme descrito na Seção 26.2.1, está no lugar).

Quando um UAC recebe um desafio, ele DEVE entregar ao usuário o conteúdo do parâmetro "realm" no desafio (o qual aparece tanto em um campo-cabeçalho WWW-Authenticate quanto em um campo-cabeçalho Proxy-Authenticate) se o dispositivo UAC ainda não sabe de uma credencial do realm em questão. Um provedor de serviço que pré-configura UA's com credenciais para seu realm deve estar ciente que os usuários não terão a oportunidade de apresentar suas próprias credenciais para esse realm quando desafiado por um dispositivo pré-configurado.

Finalmente, note que mesmo que um UAC possa localizar credenciais que estão associadas com o próprio realm, existe o potencial que essas credenciais possam não ser mais válidas ou que o servidor que desafia não aceitará essas credenciais, por qualquer razão (especialmente quando "anonymous" sem senha é submetido). Nesse exemplo, um servidor pode repetir seu desafio, ou ele pode responder com um 403 Forbidden. Um UAC NÃO PODE re-tentar requisições com as credenciais que acabaram de ser rejeitadas (embora a requisição possa ser repetida se o nonce ficou velho).


22.2 Autenticação Usuário-a-Usuário

Quando um UAS recebe uma requisição de um UAC, o UAS PODE autenticar o originador antes da requisição ser processada. Se nenhuma credencial (no campo-cabeçalho Authorization) for fornecida na requisição, o UAS pode desafiar o originador a fornecer credenciais ao rejeitar a requisição com um código status 401 (Unauthorized).

O campo-cabeçalho WWW-Authenticate da resposta PRECISA ser incluído em mensagens de resposta 401 (Unauthorized). O valor do campo é composto de pelo menos um desafio que indica o(s) esquema(s) de autenticação e parâmetros aplicáveis ao realm.




Rosenberg, et. al.          Standards Track                   [Página 195]

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.