Resumo

  • P-Preferred-Identity permitia ao usuário indicar qual identidade válida preferia usar, mas a indicação não era prova e precisava ser removida de toda mensagem encaminhada.
  • Uma P-Asserted-Identity vinda de uma origem não confiável tinha de ser substituída por um valor construído depois da autenticação ou eliminada; saber escrever o cabeçalho não conferia autoridade.

Apresentar, preferir e afirmar eram atos diferentes

O campo From do SIP já deixava o participante mostrar o nome ou pseudônimo adequado à conversa. Isso era útil para a interação humana, mas não bastava para redes telefônicas que precisavam entregar a identidade chamadora, aplicar serviços ou investigar a origem de uma chamada. Ao mesmo tempo, o assinante poderia querer que essa identidade operacional não chegasse ao destinatário. O RFC 3325 não resolveu o conflito criando um From mais forte. Separou três atos e os atribuiu a agentes diferentes.

From continuou sendo apresentação. P-Preferred-Identity era uma escolha fornecida pelo agente do usuário a um proxy diretamente confiável. Se o assinante autenticado possuísse vários números ou identificadores SIP válidos, poderia indicar qual deles desejava que a rede usasse. P-Asserted-Identity era a afirmação da rede depois da autenticação, ou depois de aceitar uma afirmação de outro membro confiável. A semelhança dos nomes escondia uma fronteira decisiva entre desejo e responsabilidade.

Ao receber uma preferência de uma entidade não confiável, o proxy podia tratá-la somente como dica. Primeiro autenticava o originador; depois comparava a dica com o conjunto de identidades válidas para aquele sujeito. Se não houvesse correspondência, podia construir outra afirmação válida ou rejeitar a solicitação. Não podia copiar a escolha e chamá-la de resultado da autenticação.

Depois da decisão, o proxy precisava remover a P-Preferred-Identity fornecida pelo usuário de cada mensagem que encaminhasse. Essa destruição não era asseio sintático. Preservava a linhagem da evidência. Se a preferência viajasse ao lado da afirmação, um sistema de registros, faturamento ou autorização poderia interpretá-las como duas confirmações independentes, embora uma tivesse sido apenas a matéria-prima da outra.

O desenho permitia que uma escolha legítima influenciasse a decisão sem ganhar vida própria como comprovante. A mensagem a jusante mostrava aquilo que a rede decidira afirmar, não o texto não verificado que participara da escolha.

Autoridade falsificada precisava desaparecer

O problema era ainda mais agudo quando o elemento não confiável enviava uma P-Asserted-Identity pronta. O nome reservado do cabeçalho não era uma credencial. Se o proxy quisesse adicionar uma afirmação, teria de autenticar o originador e usar a identidade obtida nesse processo.

Quando a entrada não confiável continha uma identidade SIP ou SIPS afirmada, o proxy devia substituir esse valor por uma única identidade SIP ou SIPS construída por ele, ou remover o cabeçalho. A identidade telefônica seguia a mesma regra. Preservar o valor antigo e apenas anexar uma marca de confiança faria a falsificação pegar carona no canal confiável. A autoridade anterior tinha de ser demolida e refeita a partir de fatos controlados pelo proxy.

Uma P-Asserted-Identity recebida de um nó confiável podia ser utilizada como se o próprio proxy tivesse autenticado o usuário. Mas essa economia herdava todas as condições do Trust Domain descrito no RFC 3324: recepção segura, associação configurada e um Spec(T) que definisse autenticação, proteção de canal, membros, padrões de privacidade e conformidade. Era confiança operacional, não certificação criptográfica intrínseca ao campo.

O próprio texto de aplicabilidade reconhecia o limite. As identidades afirmadas não eram certificadas criptograficamente, nem revelavam qual participante específico fizera a afirmação. Presumia-se que o domínio inteiro respondesse por ela. Fora de uma arquitetura que satisfizesse essas condições, a informação ficava aberta a falsificação, repetição e adulteração. O RFC 3325 não pretendia ser um passaporte geral da Internet.

A privacidade impunha uma segunda destruição

Reconstruir a identidade na entrada não encerrava a cadeia. Antes de encaminhar, cada proxy classificava o próximo salto. Para um destino confiável, preservava afirmações produzidas localmente ou recebidas de fonte confiável. Para um destino não confiável, consultava Privacy.

O novo token id obrigava a remover todos os valores P-Asserted-Identity antes de entregar a solicitação ao elemento não confiável. O valor oposto, none, exigia que as identidades afirmadas não fossem removidas por privacidade. Sem Privacy, a política do domínio, documentada em Spec(T), decidia. A recomendação era preservar a identidade quando a política permitisse, pois certos serviços poderiam falhar sem ela; porém o RFC também advertia que o encaminhamento podia revelar informação que o usuário não pedira para expor e talvez não pudesse proteger se o serviço de privacidade não estivesse disponível.

O cabeçalho podia levar um valor, ou dois quando um fosse SIP ou SIPS e o outro telefônico. Se a privacidade se aplicasse, todos tinham de ser eliminados. Remover apenas uma representação deixaria a mesma pessoa atravessar a fronteira em outra forma.

O agente receptor recebia uma obrigação semelhante. Se o elemento anterior não fosse confiável, não deveria usar P-Asserted-Identity de modo algum. Dentro do Trust Domain apropriado, políticas de implementação ou serviço poderiam decidir como exibi-la; o RFC não determinava como conciliar os tipos possíveis.

O RFC 5876 atualizou aspectos do mecanismo. Os RFCs 4474, 8224 e 8225 desenvolveram outras arquiteturas para identidade autenticada e PASSporT, enquanto o RFC 4916 tratou da identidade conectada durante o diálogo. Essas evoluções não anulam a lição histórica. A autoridade não residia em um rótulo privilegiado, mas numa transformação verificável: autenticar, limitar o conjunto válido, escolher, reconstruir, apagar a dica, classificar o próximo salto e retirar a afirmação quando a privacidade exigisse.

O RFC 3325 registrou uma distinção que continua valiosa em sistemas de evidência. Uma preferência pode ser entrada válida para uma decisão sem ser evidência dessa decisão. O proxy só produzia um comprovante próprio quando se recusava a deixar a escolha do usuário sobreviver como se fosse uma segunda testemunha.

Fontes