Resumo

  • Response era calculada com Identifier, segredo compartilhado e Challenge Value novo, sem transmitir o segredo.
  • Success registrava a igualdade local daquela troca; autenticação mútua, autorização, NCP e tráfego exigiam outras provas.

Na RFC 1994, o autenticador envia Challenge, o par devolve Response e o autenticador compara seu cálculo antes de enviar Success ou Failure. Response copia o Identifier do desafio e calcula o hash de Identifier + secret + Challenge Value. Cada novo desafio precisa mudar Identifier e valor.

Um desafio repetido com o mesmo segredo pode revalidar uma resposta capturada; um desafio previsível pode ser respondido antecipadamente. Por isso a norma recomenda unicidade e imprevisibilidade, sem prometer defesa contra escuta ativa em tempo real.

O autenticador também escolhe quando perguntar de novo, inclusive durante a fase de protocolos de rede. Essa nova pergunta cria outra prova; não prolonga a primeira. Se Success se perde, uma Response repetida para o Identifier atual deve receber o mesmo reply Code, pois retransmissão não é nova decisão.

CHAP é unilateral. A autenticação mútua exige outra negociação no sentido inverso, e PPP admite métodos diferentes em cada direção. Name localiza um segredo de sistema, não comprova pessoa ou autorização. Pela RFC 1661, cada protocolo de rede ainda precisa abrir seu NCP antes de transportar pacotes.

Fontes: RFC 1994, RFC Editor, RFC 1661, RFC 1334, IANA PPP.