ARGOMENTO:

Ciao a tutti

Avrei due domande sul processo di autenticazione CHAP (ma anche PAP).

Quello che so è che questo metodo di autenticazione prevede l'invio da parte dell'authenticator di un messaggio di challenge, cioè un numero generato in modo casuale.
Il peer calcola un hash combinando il numero casuale e la password e lo invia all'authenticator che autentica oppure no a seconda che l'hash sia corretto o meno.

La prima domanda è: chi inizia l'autenticazione visto che nella configurazione non c'è nessun comando che definisca l'authenticator?
Mi pare di aver capito che l'autenticazione sia two-way e quindi entrambi hanno il ruolo di peer e authenticator e che per trasformarla i one-way sia necessario il comando ppp authentication chap callin sulla macchina che si intende far diventare authenticator. E' corretto?

La seconda domanda è questa: mi sembra di aver capito lo scambio dell'hostname avviene necessariamente prima della fase di challenge. Questo scambio viene gestito dal protocollo LCP e non dal CHAP (o PAP a seconda del metodo di autenticazione scelto)?

Ultima cosa: ho trovato una domanda sul PTP che richiedeva l'interpretazione dell'output del comando di debug debug ppp negotiation cosa che onestamente non ho approfondito. Devo rimediare? Quanta probabilità c'è che all'esame venga richiesto di fare troubleshooting sulla base di un output simile?

Sono confuso!

Ciao Giovanni,
rispondo in ordine.

In realtà il processo di autenticazione prevede l'invio di una stringa casuale, che viene cifrata tramite MD5 dal secondo peer e restituita al mittente. Il mittente calcola autonomamente la hash della stringa da lui generata, e se coincide con quella ricevuta vuol dire che l'altro peer possiede la password corretta.

Detto questo, quando scrivi: Mi pare di aver capito che l'autenticazione sia two-way e quindi entrambi hanno il ruolo di peer e authenticator e che per trasformarla i one-way sia necessario il comando ppp authentication chap callin sulla macchina che si intende far diventare authenticator. E' corretto?

In parte. Il comando ppp authentication chap callin lo si implementa sulla parte che inizia la connessione, e serve proprio in quegli scenari dove è necessaria autenticazione unidirezionale, in cui ad esempio un router ISP autentica il dispositivo di un ipotetico cliente al fine di consentire la comunicazione.

Sulla seconda domanda invece tieni presente che l'autenticazione avviene sempre tramite una challenge seguita da una hash di ritorno, in modo che il tutto possa avvenire senza scambiare mai la password. Il parametro hostname serve solo ad indentificare il peer, non ad autenticare (per intenderci, serve a selezionare la password da utilizzare allo scopo). Detto questo, il protocollo LCP negozia i parametri della sessione (ad esempio proprio CHAP + MD5), ed una volta concordati parte l'autenticazione vera e propria.

Per la terza domanda invece cerca di prestare un minimo di attenzione alla cosa, anche se il tutto si risolve sempre piuttosto semplicemente in output intepretabilissimi (Phase is AUTHENTICATING, Phase is UP, SUCCESS, etc)

Ti riporto a tal proposito due link utilissimi all'approfondimento della questione, entrambi ovviamente dalle guide ufficiali Cisco:

Understanding and Configuring PPP CHAP Authentication
Understanding debug ppp negotiation Output

Spero sia tutto chiaro.
Un saluto e in bocca al lupo per l'esame!

Ciao Jody, grazie mille per la risposta e crepi il lupo!

Ti chiedo scusa in anticipo per il messaggio un po' lungo ma ho ancora bisogno di qualche chiarimento.

A proposito del processo di challenge volevo precisare che sulla OCG leggo che:

The challenged router runs the hash algorithm using the just-learned random number and the secret password as input, and sends the results back to the router that sent the challenge (Pag. 326 del PDF).

Che tradotto in italiano suona più o meno così:

Il router che ha ricevuto il messaggio di challenge lancia l'algoritmo di hash usando come input il numero casuale appena imparato e la password segreta per poi inoltrare il risultato al router che ha inviato il challenge.

Dunque, stando a quello che riporta il libro, lo scambio di password è presente ma praticamente indecifrabile se non si conosce il secret in quanto sotto forma di hash e combinato con con il numero casuale (CHALLENGE).
Inoltre, stessa cosa leggo sulla Wiki alla pagina "Challenge-Handshake Authentication Protocol":

1. After the completion of the link establishment phase, the authenticator sends a "challenge" message to the peer.
2. The peer responds with a value calculated using a one-way hash function on the challenge and the secret combined.

Un po' diverso è quello che vi è riportato nella documentazione Cisco alla pagina che hai linkato "Understanding and Configuring PPP CHAP Authentication":

The peer responds with a value calculated through a one-way hash function (Message Digest 5 (MD5)).

E poi:

This authentication method depends on a "secret" known only to the authenticator and the peer. The secret is not sent over the link.

Onestamente quanto riportato in questa pagina mi sembra contrastante: mi stai dicendo che il tutto dipende da un secret (una password) che non viene in nessun modo inviata attraverso il collegamento. Ma allora che senso ha la password? Mi sembra molto più logico il processo di invio di un messaggio di SECRET+CHALLENGE.

Permettimi anche di chiederti un chiarimento su questo:

Il mittente calcola autonomamente la hash della stringa da lui generata, e se coincide con quella ricevuta vuol dire che l'altro peer possiede la password corretta.

Ma se un malintenzionato si intromettesse nella comunicazione sniffando il challnge, colcolandone l'hash inviandolo poi all'authenticator, questo proverebbe che il malintenzionato è in possesso la password corretta?

Per quanto riguarda l'hostname, ho fatto delle prove abilitando il debug e usando degli hostname sbagliati. In effetti non si riceve alcun errore esplicito relativo agli hostname sbagliati e il processo di autenticazione va avanti per poi bloccarsi quando i dispositivi si accorgono che non vi è alcun matching fra user e password (mostrando gli errori "Received SENDAUTH Response FAIL e Unable to authenticate for peer" effettivamente interpretabilissimi).

Mi è invece chiaro il discorso dell'uso del comando ppp authentication chap callin e dello scopo dell'LCP. In quest'ultimo caso ho fatto un po' di sniffing con Wireshark guardando dentro ai messaggi di Configuration Request e notando come le macchine negozino fra loro l'uso del CHAP grazie al valore 0xC223 presente nel campo Authentication Protocol dell'header PPP. Spero di aver interpretato bene il contenuto del messaggio!

Ps: ti allego la domanda e il relativo exhibit da cui deriva la richiesta di chiarimenti.

Ciao Giovanni,
in realtà non vi è alcun contrasto tra le due fonti, dicono esattamente la stessa cosa. La funzione di hashing serve proprio a NON scambiare la password (cosa che avveniva con il PAP): quello che viene scambiato è il risultato della funzione, e non la password stessa.

Tra l'altro il processo di autenticazione a differenza del PAP viene reiterato nel tempo.

Infine, la traduzione che proponi del passaggio "The challenged router runs the hash algorithm using the just-learned random number and the secret password as input, and sends the results back to the router that sent the challenge" direi sia corretta, motivo per il quale non capisco quando poi affermi che "lo scambio di password è presente ma praticamente indecifrabile". E' proprio questo il punto, non viene affatto scambiata la password, ma solo il risultato di una funzione di hashing che prevede l'uso di una certa chiave, che rende possibile il ricavo del medesimo risultato (detto Message Digest o hash MD5) solo se si possiede la stessa chiave. Quindi lo scambio durante l'autenticazione riguarda solamente stringhe casuali e le relative hash MD5, e mai la chiave utilizzata allo scopo.