IPsec AUTH payload

[Giuseppe Bianchi < >]

Sono dettagli tecnici ben lungi dall'essere stati affrontati a lezione  
(traduzione: nessuno vi chiedera' MAI di saperli), e le slides a tal  
proposito non sono sufficienti senza una spiegazione supplementare  
(che per motivi di tempo non abbiamo potuto fare).

Comunque, per chiarire la confusione:

> In particolare è presente il campo Auth che dovrebbe servire ad  
> autenticare i >messaggi scambiati precedentemente e le entità  
> comunicanti. Sulle slide è scritto che nel caso in cui le due entità  
> si scambino i >certificati l'autenticazione avviene utlizzando le  
> chiavi private associate >alle chiavi pubbliche presenti nei  
> certificati...e fino a qui tutto bene

E fin qui tutto bene. Importante notare che NON e' specificato il modo  
con cui i due peer si debbano autenticare, ma e' solo riservato un  
eventuale CAMPO per farlo!! La norma e' ovviamente usare certificati,  
ma non lo ha ordinato il dottore che sia OBBLIGATORIO farlo. E' per  
esempio possibile usare molto piu' semplicemente una pre-shared key, o  
usare EAP.

> Nel caso in cui però le entità non si scambino i certificati c'è  
> scritto che >in qualche modo questo campo che dovrebbe fungere da  
> autenticatore del entità >viene prodotto attraverso due delle 7  
> sottochiavi derivanti dallo Skeyseed. Mi >rimane un pò ostico capire  
> come attraverso dei derivati di una chiave >concordata si possano  
> autenticare le identità dei peers.

E' questa la confusione (ma e' ovvio: dalla lettura delle sole slides  
neanche Einstein riuscirebbe a decodificare cosa succede!).  
L'autenticazione infatti avviene FIRMANDO un qualcosa. Tale qualcosa  
include del testo che, per "legge" DEVE CONTENERE, OLTRE ad altre cose  
(ed in particolare i payload scambiati precedentemente), ANCHE le  
chiavi SK_pi o SK_pr (o per essere piu' precisi dei loro derivati  
opportuni). In questo senso la slide dice che per GENERARE il PAYLOAD  
del campo auth si usa come input anche queste chiavi. NON dice "per  
FIRMARE" (ed infatti queste chiavi non c'entrano nulla con la firma,  
ma sono "firmate" :-) ).

> Mi vengono 2 dubbi:
> 1) Non ho capito cosa c'è scritto sulla slide

Spero che ora sia un pochino piu' chiaro e che almeno sia chiaro dove  
era la confusione. Ma l'unico modo per chiarirlo a fondo e' leggersi  
direttamente la RFC di IKEv2 (la 4306) - il tema dell'autenticazione  
dei peer e' trattato in 3-4 sezioni a seconda dei metodi usati.


> 2) Come avviene l'autenticazione delle entità senza lo scambio di certificati

come dicevo sopra, con segreto condiviso o facendo partire EAP.